[fluid-dev] Questions about Gleam

[Guillaume Pothier]

> Well, actually I think the freed list is perfect for your purposes.  If I
 > understand what you want to do correctly, you don't need to add the events
 > back to the synth as soon as they're consumed, you could add them all at the
 > repeat point (adding events is equally fast irrespective of the number of
 > events).  To do that you only need a list of the events that have been
 > consumed i.e. the freed list.

 Well, actually it is a bit more complicated: I have several midi
 files, or tracks, that are played in a loop at the same time, each
 with a different duration, so each track might have to be played a
 great number of times before they all start at the same time again.

 So what I am doing now is the following: each track behaves like an
 iterator, and whenever I need to inject a new event into the synth, I
 take the event from the track whose current event has the smallest
 timestamp. When a track goes past its last event, it starts over
 again, but adding an offset (equal to the track's duration) to each
 event's timestamp so that they are played again at the right time.

 With this scheme I never have to free the events: whenever I am
 notified that the synth has consumed an event, I just pop another
 event from the set of tracks. Actually, the tracks hold
 GleamEventNodes, so those are also allocated once and for all.

 Now, the issue is how to be notified that the synth has consumed an
 event. I know I can do it with the condition sync event: I could
 insert one of them every N events, and have a thread waiting for them,
 and inserting N "new" events each time N events have been consumed. I
 would also have to clean up the freed events list. Also, it seems that
 condition sync events cannot be reused (tell me if I'm wrong), so I
 would have to allocate and free them as needed.

 The solution I'm using now, instead, is the one I mentioned
 previously, which consists in providing a customized subclass of
 GleamList, with a virtual addNode method. Works like a charm, and
 requires much less code.

 Regards,


g

 > I don't think adding the null check is a good idea, because the freed list
 > is going to be needed almost by every application, and making it optional
 > would be misleading for the application writer.  The application almost
 > certainly wants to do something with the events after they are consumed,
 > otherwise they are just sitting there using memory for no reason.  And the
 > application definitely must not do anything with the queued events *before*
 > they are consumed, or Gleam will get confused.  In short, the freed list
 > contains precisely the events the application almost certainly wants to do
 > something about.



 >
 > Regards.
 >
 > --
 > Miguel
 > Check out Gleam, an LGPL sound synthesizer library, at
 > http://gleamsynth.sf.net
 >
 >
 >
 > On Tue, Apr 22, 2008 at 4:57 AM, Guillaume Pothier <address@hidden>
 > wrote:
 > > Hi Miguel, I understand the rationale much better now. I still think
 > > that having a custom callback (eg. a pointer to a function taking a
 > > Node) would provide more flexibility than systematically adding the
 > > events to a list, and I think the overhead is negligible compared to
 > > the cost of calculating even a single sample, but you're the boss here
 > > ;-)
 > > Anyway, it would be very cool if the freed events list was at least
 > > optional, as in my case I never have to free the events but rather
 > > reinject them in the synth. Would it be ok to add a null check of
 > > firstEvent.freeList in GleamSynth::readAudio?
 > > Regards,
 > > g
 > >
 > >
 > >
 > >
 > >
 > > On Mon, Apr 21, 2008 at 3:08 PM, Miguel Lobo <address@hidden> wrote:
 > > > Events can be generated and consumed at quite a high rate, so event
 > memory
 > > > management can be critical for performance and especially latency.
 > > > Applications might implement different solutions to deal with this, so I
 > > > wanted to keep GleamCore flexible in this area.  In fact, the
 > non-optional
 > > > parts of GleamCore don't do any allocation or de-allocation of events;
 > the
 > > > MIDI converter does, but it's just meant to be a helper to deal with
 > MIDI
 > > > data and its use by the application is completely optional.  Perhaps it
 > > > should be moved out of GleamCore, as nothing in GleamCore depends on it.
 > > >
 > > > Another general target is to avoid any calls to memory allocation
 > functions
 > > > (which have potentially unbounded duration) in the synthesis thread.  At
 > the
 > > > moment we're still quite far from that target, but the freeing of events
 > is
 > > > the most important place, I think, where this idea impacts design rather
 > > > than just implementation, so I wanted to try to get it right as early as
 > > > possible.
 > > >
 > > > Virtual functions have a cost both in compile-time optimization and
 > run-time
 > > > performance and should be avoided in time-critical code whenever
 > reasonable.
 > > > Events could have a virtual callback to notify of their consumption, but
 > > > that would be quite expensive.  The intended way to know when a point
 > has
 > > > been reached in the event queue is the condition sync event, which has
 > > > minimal cost for the synthesis thread.  An example of its usage its
 > provided
 > > > in playmidi.cpp:
 > > >
 > > >
 > > >     /* add a condition sync event so we know when all events have been
 > > > played */
 > > >     GleamConditionSyncEvent&
 > > > endEvent(events.addType<GleamConditionSyncEvent>()());
 > > >     endEvent.freeList = &freedEvents;
 > > >
 > > >      endEvent.time = lastTime;
 > > >
 > > > [...]
 > > >
 > > >     /* wait until the end event is played */
 > > >     endEvent.conditionSync.wait();
 > > >
 > > > Hope these answers some of your questions.
 > > >
 > > > Regards,
 > > > Miguel
 > > >
 > > >
 > > >
 > > >  On Sun, Apr 20, 2008 at 4:13 PM, Guillaume Pothier <address@hidden>
 > > > wrote:
 > > > > Hi Miguel, thanks for your help.
 > > > > Indeed I think the autorepeat feature should be implemented outside of
 > > > > GleamCore. Maybe I wasn't very clear in my previous mail, but what I
 > > > > wanted to do was to provide a subclassed list to the midi loader so
 > > > > that I could be notified when events are consumed. So all this extra
 > > > > code was outside of Gleam, the only change I had to do to Gleam itself
 > > > > was to declare the addNode methods of GleamList virtual.
 > > > > I'm wondering, what is the intended use of this freed events list? I
 > > > > guess it is for deallocating the memory of the events, right? I was
 > > > > thinking that it might be more generic to use a callback, rather than
 > > > > storing the events in a list. So if someone needs to have a list of
 > > > > freed events, they can do it by providing a proper callback. If
 > > > > someone wants to do something else, like this autorepeat stuff, or
 > > > > directly deleting the events, they can also do it. What do you think?
 > > > > g
 > > > >
 > > > >
 > > > >
 > > > >
 > > > >
 > > > > On Mon, Apr 21, 2008 at 3:20 AM, Miguel Lobo <address@hidden> wrote:
 > > > > > Sorry again, I did not try compiling with the debug log disabled.
 > It
 > > > should
 > > > > > work now.
 > > > > >
 > > > > > It's important to keep the intended purpose of GleamCore as simple
 > and
 > > > easy
 > > > > > to understand as possible (and reasonable), so I think a feature
 > like
 > > > your
 > > > > > propose would be better implemented outside GleamCore.  For example,
 > in
 > > > the
 > > > > > playmidi example, you have this code:
 > > > > >
 > > > > >     /* add a condition sync event so we know when all events have
 > been
 > > > > > played */
 > > > > >     GleamConditionSyncEvent&
 > > > > > endEvent(events.addType<GleamConditionSyncEvent>()());
 > > > > >     endEvent.freeList = &events;
 > > > > >      endEvent.time = lastTime;
 > > > > >
 > > > > > [...]
 > > > > >
 > > > > >     /* wait until the end event is played */
 > > > > >     endEvent.conditionSync.wait();
 > > > > >
 > > > > > At that point you could add all events again instead of exiting.
 > > > > >
 > > > > > Hope this answers your question.
 > > > > >
 > > > > > --
 > > > > > Miguel
 > > > > > Check out Gleam, an LGPL sound synthesizer library, at
 > > > > > http://gleamsynth.sf.net
 > > > > >
 > > > > >
 > > > > >
 > > > > >
 > > > > > On Sat, Apr 19, 2008 at 11:23 PM, Guillaume Pothier
 > <address@hidden>
 > > > > > wrote:
 > > > > > > Hi Miguel, thanks for your reply!
 > > > > > > I updated my working copy and now I have other errors (string.h is
 > not
 > > > > > > imported in debuglog.h, and bad call at sf2voice.cpp:551; for now
 > I
 > > > > > > just commented the offending statement out)
 > > > > > >
 > > > > > > I started playing around with Gleam and I was wondering how could
 > I
 > > > > > > implement a "repeat" feature: I would like to load a short midi
 > file,
 > > > > > > and have it playing over and over again. I thought that the
 > simplest
 > > > > > > mean of doing that would be to overload the freeList so that
 > whenever
 > > > > > > an event is added to it, I push it back to the synth, with an
 > updated
 > > > > > > timestamp. First of all, does it sound like a reasonable solution?
 > > > > > > Second, to to that I would need the addNode method of GleamList to
 > be
 > > > > > > virtual. Could that be?
 > > > > > >
 > > > > > > Regards,
 > > > > > > g
 > > > > > >
 > > > > > >
 > > > > > >
 > > > > > >
 > > > > > > On Sun, Apr 20, 2008 at 2:51 PM, Miguel Lobo <address@hidden>
 > wrote:
 > > > > > > > Hi,
 > > > > > > >
 > > > > > > > Gleam is still very related to fluidsynth so I hope people won't
 > get
 > > > > > > > offended if there are questions about it here.  However, I don't
 > > > always
 > > > > > read
 > > > > > > > all posts in this list (especially when I'm very busy at work
 > like
 > > > in
 > > > > > the
 > > > > > > > last few weeks), so please CC me on any message about Gleam to
 > be
 > > > sure
 > > > > > it
 > > > > > > > doesn't get lost.
 > > > > > > >
 > > > > > > > The reason Gleam from SVN wasn't compiling was that I had a
 > change
 > > > half
 > > > > > > > checked-in.  I've now completed the check-in, so it should
 > build.
 > > > This
 > > > > > > > change, which is what I've been working on recently, basically
 > adds
 > > > an
 > > > > > > > interface to generate useful debug information.  I'm trying to
 > use
 > > > it to
 > > > > > > > track down severe clicking problems that seem to appear in some
 > > > > > particular
 > > > > > > > songs.
 > > > > > > >
 > > > > > > > In response to your other questions:
 > > > > > > >
 > > > > > > > - Gleam might well be more CPU-intensive than fluidsynth at this
 > > > point;
 > > > > > I
 > > > > > > > haven't checked.  The reason is I'm focusing on getting
 > > > functionality
 > > > > > right
 > > > > > > > before looking into performance optimisations.  Anyone who wants
 > to
 > > > look
 > > > > > > > into the latter is welcome right now, of course.
 > > > > > > >
 > > > > > > > - Gleam has been designed with the idea of being able to combine
 > > > > > multiple
 > > > > > > > synthesis models (or "subsynths" as I've called them) in a
 > single
 > > > > > logical
 > > > > > > > synthesizer.  Currently only the only implemented subsynth is
 > based
 > > > on
 > > > > > the
 > > > > > > > SF2 spec, but I hope other subsynths will be added in the
 > future.
 > > > > > > >
 > > > > > > > As always, anyone who wants to do *any* type of development on
 > Gleam
 > > > > > will
 > > > > > > > have my full support as far as answering questions and so on.
 > > > > > > >
 > > > > > > > --
 > > > > > > > Miguel
 > > > > > > > Check out Gleam, an LGPL sound synthesizer library, at
 > > > > > http://gleam.sf.net
 > > > > > > >
 > > > > > > >
 > > > > > > >
 > > > > > > > On Sat, Apr 19, 2008 at 5:28 PM, Guillaume Pothier
 > > > <address@hidden>
 > > > > > > > wrote:
 > > > > > > > >
 > > > > > > > >
 > > > > > > > >
 > > > > > > > > Hi,
 > > > > > > > > I hope this place is more or less appropriate to ask questions
 > > > about
 > > > > > > > Gleam.
 > > > > > > > > So here are a few questions:
 > > > > > > > >
 > > > > > > > > - Gleam from svn is not building right now, I get those
 > errors:
 > > > > > > > > /home/gpothier/tmp/gleamsynth/GleamCore/src/sf2/sf2voice.cpp:
 > In
 > > > > > > > > constructor 'GleamSF2Voice::Private::Private(GleamCore&,
 > > > > > > > > GleamSF2SubSynth&, GleamSynthConfigurationV1&,
 > GleamSF2Voice&)':
 > > > > > > > >
 > /home/gpothier/tmp/gleamsynth/GleamCore/src/sf2/sf2voice.cpp:169:
 > > > > > > > > error: 'class GleamArray<GleamSF2Generator>' has no member
 > named
 > > > > > > > > 'setCountWithoutCopy'
 > > > > > > > > /home/gpothier/tmp/gleamsynth/GleamCore/src/sf2/sf2voice.cpp:
 > In
 > > > > > > > > member function 'bool GleamSF2Voice::on(const GleamNoteEvent&,
 > > > > > > > > GleamSF2Zone&)':
 > > > > > > > >
 > /home/gpothier/tmp/gleamsynth/GleamCore/src/sf2/sf2voice.cpp:235:
 > > > > > > > > error: 'class GleamArray<GleamSF2Modulator>' has no member
 > named
 > > > > > > > > 'count'
 > > > > > > > >
 > /home/gpothier/tmp/gleamsynth/GleamCore/src/sf2/sf2voice.cpp:236:
 > > > > > > > > error: 'class GleamArray<GleamSF2Modulator>' has no member
 > named
 > > > > > > > > 'count'
 > > > > > > > > /home/gpothier/tmp/gleamsynth/GleamCore/src/sf2/sf2voice.cpp:
 > In
 > > > > > > > > member function 'void GleamSF2Voice::updateModulators(bool)':
 > > > > > > > >
 > /home/gpothier/tmp/gleamsynth/GleamCore/src/sf2/sf2voice.cpp:722:
 > > > > > > > > error: 'class GleamArray<GleamSF2Modulator>' has no member
 > named
 > > > > > > > > 'count'
 > > > > > > > >
 > > > > > > > > Is it okay to replace all those "count" by "capacity"?
 > > > > > > > >
 > > > > > > > > - Is Gleam more CPU-intensive than fluidsynth?
 > > > > > > > > - I'd like to eventually have a fixed-point synthesizer. If I
 > have
 > > > > > > > > time I might have a try at writing one. Where would it fit in
 > the
 > > > > > > > > design of Gleam?
 > > > > > > > >
 > > > > > > > > Regards,
 > > > > > > > > g
 > > > > > > > >
 > > > > > > > >
 > > > > > > > > _______________________________________________
 > > > > > > > > fluid-dev mailing list
 > > > > > > > > address@hidden
 > > > > > > > > http://lists.nongnu.org/mailman/listinfo/fluid-dev
 > > > > > > > >
 > > > > > > >
 > > > > > > >
 > > > > > >
 > > > > >
 > > > > >
 > > > >
 > > >
 > > >
 > > >
 > > > --
 > > >
 > > > Miguel
 > > > Check out Gleam, an LGPL sound synthesizer library, at
 > > > http://gleamsynth.sf.net
 > >
 >
 >