Hello, well, it took me some time to delves into this 18 years old code, that has moreover changed quite a bit since.
You are right, the real time client can rely on the currentMs time of the sequencer. No need for the fluid_curtime(). Cheers Antoine > Le 11 déc. 2019 à 11:57, Tom M. via fluid-dev <fluid-dev@nongnu.org> a écrit : > > > 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
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
