Re: [fluid-dev] Questions about Gleam

[Guillaume Pothier]

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