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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > > 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 <[EMAIL PROTECTED]> 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 > <[EMAIL PROTECTED]> > > > > > 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 > > > > > > [email protected] > > > > > > http://lists.nongnu.org/mailman/listinfo/fluid-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Miguel > Check out Gleam, an LGPL sound synthesizer library, at > http://gleamsynth.sf.net _______________________________________________ fluid-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/fluid-dev
