Antoine, I was hoping you are listening :) It is not quite clear to me why you need the system timer for scheduling those patterns, could you pls. elaborate? I would assume that you add a FLUID_SEQ_TIMER event to the synth and once you get the callback via fluid_event_callback_t you are provided with a timestamp by the sequencer. The timestamp currently comes from fluid_sequencer_get_tick(). Why does it matter that you need fluid_curtime() rather than currentMs which is provided by the synth?
seq->useSystemTimer ? (int) fluid_curtime() : fluid_atomic_int_get(&seq->currentMs); > then we open ourselves up to bug reports where people ask: why does this > (broken) MIDI file sound different in Fluidsynth than in almost all other > MIDI players? Not quite, because for now this change would be limited to the sequencer only, the fluid_player will be unchanged. The sequencer is a fluidsynth specific component, so I do believe that we have the freedom to tweak things here and there. So far I can't see any drawbacks of the event ordering I've proposed. And if we ever decide to make the fluid_player use the sequencer, we can just assign an alternative ordering function internally, that restores the FIFO ordering. > Why would we need a deprecation period? Are you intending to change the > behaviour or API of the sequencer? I don't think an API change will be necessary. The deprecation just came to my mind because of the possible transition from C to C++. > it surely can also be improved using an optimization of the current C > implementation The problem seems to be the heavy usage of linked lists. Lists have a poor cache performance. One would need to rewrite it using a contiguous container... > Couldn't we simply implement that kind of heap/queue in C? ... we could. But I'm not a friend of adding yet another custom heap/queue implementation to the code base, when we can simply use one from a library. [For the record, I'm appending Marcus' last mail below, which he mistakenly only sent to me] Tom 10. Dezember 2019, 18:26:35 CET: > Hi again, > > Am Di., 10. Dez. 2019 um 11:03 Uhr schrieb Tom M. <tom.m...@googlemail.com>: > > > > Why is "Note-On last" the better order? How do you know that that > > > special (and seemingly Fluidsynth specific) ordering is what the author of > > > the MIDI file wanted? > > > > When something happens at the same tick, I don't claim to know anything. > > My proposed solution is simply the best guess I can come up with in such a > > situation. Two examples: > > > > a) NoteOn and ProgChange happen in that order at the same tick. Would it > > make sense to turn on the note using the old instrument, although we are > > just about to receive a new program at the same tick? I don't think so. The > > NoteOn, although first in the stream, should use the new program. > > > > b) NoteOn at tick 0, after e.g. 100 ticks: NoteOn and NoteOff. All three > > note events happen in the given order on the same channel and trigger the > > same key. How would fluidsynth interpret them currently? The first note is > > triggered, it sounds for a while until the second NoteOn arrives. That > > second NoteOn kills overlapping notes, i.e. it kills the first note. But > > oops, just after that second note was turned on, it will be turned off > > right again, because we have a NoteOff at the same tick, which apparently > > was meant to turn off the first note though. > > > > For case b) I have MIDI files that do such things. Ofc you are right > > Marcus, technically the MIDI converter program is to blame. I cannot really > > change the converter though. I would alternatively need to handle those > > cases in my program. I was just thinking of a possibly acceptable way for > > fluidsynth to handle such "corner-cases". > > > > I understand where you are coming from and I share your pain. But the ugly > truth is: MIDI events on the same tick don't have a defined order in the > spec. The only real extra information that we have that might carry some > extra information about the intention of the author of the file is the > order of events in the stream. All other orderings are completely > artificial and by definition non-standard. And as you mention that almost > all MIDI players use the stream order in these cases, that comes close to a > agreed solution by the community in my opinion. And we would have to have a > real good reason not to go along with the established standard. > > If we implement our own ordering, then we open ourselves up to bug reports > where people ask: why does this (broken) MIDI file sound different in > Fluidsynth than in almost all other MIDI players? And responding with > "because it's broken" doesn't really work, because it works in almost all > other players. > > > > > > 3. Simpler implementation? > > > What trips me up though: if your program was really stuck in that loop > > > for seconds, I'm wondering how many events you were actually adding to the > > > sequencer... Millions? > > > > I'm takling about ten-thousands of events. Here are some measurements: > > > > Wow, that's quite a difference, thanks for the info! > > > > > > 5. The system timer > > > isn't there a global timing event that MIDI devices can send to each > > > other to synchronise playback position and playback speed? > > > > You seem to refer to "System Real Time Messages". But I don't know how > > this could be integrated into fluidsynth. > > > > On second thought, this is probably out of scope for Fluidsynth. And to be > honest, I don't really understand why we have two timing sources. > > > > > adding another implementation in C++ is not cleanup IMO... it adds more > > > technological debt because we now have to keep two different > > > implementations in sync. > > > > Having two implementations would be temporarily. First add an > > "experimental" C++ impl., then deprecate the current C implementation while > > using the C++ impl. by default and finally remove the deprecated. > > > > Why would we need a deprecation period? Are you intending to change the > behaviour or API of the sequencer? > > > > But I do wonder: what can C++ do that C can't? And especially: why can > > > C++ do it faster? > > > > Simply that I'm more familiar how to do those things in C++ rather than > > with glib. And I'm not sure what Carlo, you, and the other embedded system > > guys said, if we fortify the glib dependency. I'm not sure how they think > > about a dependency to the C++ std lib either... > > > > I'm not worried about glib, but Carlo probably has quite a different > opinion :-) > > If what I found online is correct, then std::priority_queue uses a max-heap > structure to store the data, hence its speed. Couldn't we simply implement > that kind of heap/queue in C? I'm sure there is tried and tested code > around that we could simply adopt. > > Cheers, > Marcus >
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
