Started by EthanF4D, February 13, 2018, 08:00:16
QuoteAfter I set_position_order_row(), the get_current_speed() and get_current_tempo() does not reflect the change of tempo/speed on current row.
QuoteIn my experiment I know that, if the play_note() happens between rows, the beginning of notes will not be rendered (especially noticeable for drums).
Quote from: Saga Musix on February 13, 2018, 12:41:50QuoteIn my experiment I know that, if the play_note() happens between rows, the beginning of notes will not be rendered (especially noticeable for drums).That doesn't sound quite right to me... new notes should be able to be "queued" (via play_note) at any point in time, but they should always start playing on the next tick - and in particular, the start of the sample should definitely not be missing. Do you have a minimal example where this happens?
int channels = 2; OpenMPTWrapper.openmpt_module_read_interleaved_float_stereo(Module.ModulePtr, 48000, 1, PeekBuffer); Tempo = OpenMPTWrapper.openmpt_module_get_current_tempo(Module.ModulePtr); Speed = OpenMPTWrapper.openmpt_module_get_current_speed(Module.ModulePtr); NumberOfSampleRequested = (int)(SampleRate * 2.5 * Speed / Tempo); Array.Copy(PeekBuffer, Buffer, 1 * channels); OpenMPTWrapper.openmpt_module_read_interleaved_float_stereo(Module.ModulePtr, 48000, (ulong)NumberOfSampleRequested - 1, &Buffer[1 * channels]);
Quote from: manx on February 13, 2018, 12:26:08The plan is to add functionality to libopenmpt which allows querying the remaining samples until the next tick (and thus also row).That way, I think all your use cases could be handled by issuing play note at exactly the right position.If you can query directly how many sample frames until a tick or row is done, there would also be no need to do the tempo calculations yourself.
Quote from: EthanF4D on February 14, 2018, 07:41:19Thanks for reply Saga. Previously I didn't lock the module for multithread (audio thread keeps pulling samples, main thread play/stop notes), so it could be the main cause of missing the beginnings. Now that I lock it, the problem seems fixed.
Quote from: EthanF4D on February 14, 2018, 07:41:19Good to know that the notes should always start playing on the next tick, does this mean it will not be row-boundary precise?
Quote from: EthanF4D on February 14, 2018, 07:41:19for the original song, say on channel 1, the drum is hit every 4 rows. If I mimic this part by current API play_note and stop_note, they may actually be played on 4 different channels and not undergoing the regular 'note cut/note fade' as if replaced by another note on the same channel. Will this part be subject to change in future?
Quote from: EthanF4D on February 14, 2018, 13:28:40Thanks for the detailed explanation regarding ticks. Because I can only query the API for commands in row granularity, and the fact that I could "play a row" in OpenMPT tracker, this led me to wrongly assume that it is row-boundary precise.
Quote from: EthanF4D on February 14, 2018, 13:28:40This is audible as 3 notes and because being on the same channel, will there be some processing such as stop the sustain of the previous note and/or cross fade into the new note's beginning?
Quote from: EthanF4D on February 14, 2018, 13:28:40If this is the case it would sound different than they play/stop individually on different background channels, although arguably may not be such a big deal. A play_note_on_channel() could be beneficial and it will be the programmer's duty to call it on same background channel returned from the first play_note().