0001253: Shifting entire sample map - OpenMPT Issue Tracker

ID	Project	Category	View Status	Date Submitted	Last Update

0001253	OpenMPT	Feature Request	public	2019-08-24 08:08	2019-08-25 10:36

Reporter	kinnikinnick	Assigned To
Priority	none	Severity	feature	Reproducibility	always
Status	new	Resolution	open

Summary	0001253: Shifting entire sample map
Description	I know that this sounds weird, but I request that the feature to shift an entire sample map on an instrument should be added. For example: let's say you've made a good guitar sample with like 200 samples, and then you realize it's out of tune. You've made a really long song, and you haven't put the guitar on it's own channel, so you can't just transpose the channel. But at the same time you can't transpose the instrument since the samples will sound really weird, so you have to manually remap all of the 200 samples on the instrument. Obivously that's exaggerated, but you can probably tell what I'm reffering to. I think you should be able to transpose an instrument and also shifting the sample map accordingly. But better, just give the feature to shift the sample map around to your liking. I don't know how hard that is to implement, though.
Tags	No tags attached.

Has the bug occurred in previous versions?
Tested code revision (in case you know it)

Saga Musix 2019-08-24 12:29 administrator ~0004019	Yeah, definitely a useful idea, but one has to be careful about losing the bottom/top notes in the map when shifting (but the same issue exists when transposing it).

kinnikinnick 2019-08-25 06:34 reporter ~0004020	I thought about that when commenting this, but I thought it's not much trouble if it's handled like when transposing the notes. Storing beyond the usable area (probably without storing it when the module is saved) would be a bit memory-intensive, but I suppose it's feasible for somebody with a 64-bit computer. I think it's fine just how it is right now. You just gotta be careful.

Saga Musix 2019-08-25 10:36 administrator ~0004023	Storing beyond the usable area (probably without storing it when the module is saved) would be a bit memory-intensive, but I suppose it's feasible for somebody with a 64-bit computer We are talking about amounts that can be measured in bytes here. Storing the extra data isn't the issue really, but both storing it and not storing it can bring unwanted consequences when shifting the sample map. This is just an inherent issue of trackers' concept of having 1:1 assignments rather than ranges (like you have them in soundfonts) and I think that indeed being careful about it is just the best way to deal with it.

Date Modified	Username	Field
2019-08-24 08:08	kinnikinnick	New Issue
2019-08-24 12:29	Saga Musix	Note Added: 0004019
2019-08-25 06:34	kinnikinnick	Note Added: 0004020
2019-08-25 10:36	Saga Musix	Note Added: 0004023