[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [fluid-dev] We need a new, better sequencer!
From: |
Marcus Weseloh |
Subject: |
Re: [fluid-dev] We need a new, better sequencer! |
Date: |
Thu, 12 Dec 2019 13:38:09 +0100 |
Am Do., 12. Dez. 2019 um 12:03 Uhr schrieb Tom M. via fluid-dev
<address@hidden>:
> Here, we are talking about a corner-case, when events have the same
> timestamp. [...] Implementations are subject to change. And because this
> corner-case hasn't been communicated to the user, I don't really consider it
> to be a change in behaviour.
Ok, that sounds reasonable.
> I was thinking about how to turn this undefined behaviour in a well-defined
> one (at least for fluidsynth).
That also sounds good. I think we only differ in our idea of what
would be the best or most natural behaviour. :-)
> Attached is a (simplified) MIDI file illustrating the problem. It starts two
> different notes at the same time. After some delay it starts the same note
> pair again, after that but still at the same tick, it turns off the notes.
> After another delay, it starts the same two notes again and turns them off
> right at the same tick.
> When playing it with fluidsynth you will only hear the first note pair
> sounding, ie. after 8 sec. there'll silence. When you import the MIDI in an
> editor like rosegarden, qtractor or MuSE, they correctly recognize that there
> are two note pairs, making the MIDI file sound for 16 sec. (The treatment of
> the zero length notepair at the end differs between the programs though...
> not of interest to us anyway). LMMS however, only recognized the first note
> pair.
Thanks, very interesting, especially the MuSE, Rosegarden et al.
behaviour! Still... I don't understand how their behaviour is
"correct" and Fluidsynths behaviour isn't. It seems like we simply
have different "gut feelings" about what's right here. As I mainly
deal with real-time MIDI, the event order makes absolute sense to me.
Doing custom orderings in the synth just feels wrong. But this is such
a small change and in a part of Fluidsynth that I don't really use, so
let me just register my -0 for this change and then I'll shut my mouth
:-)
> In case somebody is interested in my progress with the C++ implementation,
> here's the current dev branch:
> https://github.com/FluidSynth/fluidsynth/commits/new-seq2
Looks nice and clean... but I don't speak C++ so I can't really
comment in any detail. And that is also a reason I'm -0 to -1 on
adding the C++ dependency and (more importantly) C++ code to
Fluidsynth.
Cheers
Marcus
- [fluid-dev] We need a new, better sequencer!, Tom M., 2019/12/09
- Re: [fluid-dev] We need a new, better sequencer!, Marcus Weseloh, 2019/12/09
- Re: [fluid-dev] We need a new, better sequencer!, Tom M., 2019/12/10
- Re: [fluid-dev] We need a new, better sequencer!, Antoine Schmitt, 2019/12/10
- Re: [fluid-dev] We need a new, better sequencer!, Tom M., 2019/12/11
- Re: [fluid-dev] We need a new, better sequencer!, Marcus Weseloh, 2019/12/11
- Re: [fluid-dev] We need a new, better sequencer!, Marcus Weseloh, 2019/12/11
- Re: [fluid-dev] We need a new, better sequencer!, Tom M., 2019/12/12
- Re: [fluid-dev] We need a new, better sequencer!,
Marcus Weseloh <=
- Re: [fluid-dev] We need a new, better sequencer!, Antoine Schmitt, 2019/12/12
- Re: [fluid-dev] We need a new, better sequencer!, Tom M., 2019/12/13
- Re: [fluid-dev] We need a new, better sequencer!, Antoine Schmitt, 2019/12/12