:-) On Thursday 23 July 2009, Gabriel M. Beddingfield wrote: > Hi Jakob, > > On Thu, 23 Jul 2009, Jakob Lund wrote: > > transport_redesign_2 branch. This is really cool! I like the idea of > > Thanks! > > > I'm not so sure about the SeqScript idea though, it seems that every note > > (that has length set) gets two events associated with it instead of one, > > which could complicate things. Why not just use Note objects as before? > > the sampler still uses them internally, and in that process, various > > fields on the Note get manipulated (notably m_fSamplePosition). > > Good point. That's something I'm not terribly happy about with SeqScript. > The way that Note gets wrapped inside of SeqEvent is a little clunky. > > Here's the ideas that went in to what we have today (...for right or > wrong...): > > + Make Note very lightweight. Currently Note carries > a QString (inherited from Object), all the ADSR > state parameters (which should be handled by the > voice making the noise), some filter paramters, > etc., etc. Make it something easy and fast > to copy. > > + Remove the notion of position from the Note > itself. Conceptually, a note is a pitch > (instrument), length, velocity, etc. The position > of the note in the song is information _about_ > the note, but is not part of the note itself. > > + Things like m_fSamplePosition shouldn't be in > Note (conceptually). It is a book-keeping, > implementation detail of the instrument. (Info. > _about_ the note... i.e. how long we've been > playing this here note.)
Yes.. So the idea is that eventually we wouldn't need copies of the notes at all? I guess that could be nice. But what if a note was deleted (from the GUI) while the song is playing (eg. if that note had already been scheduled bt the lookahead)? this could easily happen, so we'd have to be very carefull. What I'm saying is, once the note has been scheduled, we can't rely on it being present in the Song (Pattern) anymore, so we'd have to copy every piece of information from it anyway. > > + Create an intermediate language to communicate > Note events. (In retrospect, this is similar > to MIDI.) This de-couples inputs and outputs. > The scripting language (thus "SeqScript") would > be something like this: > > time=0 Note On, Inst #3, Vel=90 > time=0 Note On, Inst #2, Vel=20 > time=24 Note Off, Inst #3, Vel=x > time=36 Note On, Inst #1, Vel=119 > ... > > The times are relative to the frame in the > current process cycle. Now the Sampler doesn't > care about note position or ticks or anything. > It just plays Note at frame Z. But still, all those note off events bother me - when scheduling a note, old note-off's lying between the new note-on and the new note-off would have to be deleted. Going through the script (ie. linked-list) again and again to do this could be overly expensive, don't you think? > > + The container that holds all the events in > SeqScript should be a pre-allocated, fixed > block of memory. > > FWIW, The now-abandoned 'transport_redesign' was closer to these goals... > but further from release. :-) > > > A full implementation of the SongSequencer would also have to keep some > > copied notes around for lookahead purposes (I imagine setting a floating > > point tick position on them first [to include humanize etc.], putting > > them in a priority queue based on that tick position, and then only > > converting to frame positions for notes that will actually _play_ during > > the current buffer cycle.) It seems to me as the SeqScript just adds > > anothe round of copying Note objects (I might very well be wrong here) ? > > Short version: SongSequencer would go ahead and schedule the notes in > SeqScript, even though they are beyond the current process() cycle. > SeqScript keeps those notes, but when sending to Outputs... only feeds the > stuff for the current cycle. (See SeqScript::consumed(), > and SeqScript::end_const(frame_type)). > > When scheduling notes, SongSequencer has to look ahead an appropriate > amount and schedule all those events (rendering any randomization values > now). So, there will probably be a cursor where SongSequencer says to > itself, "I've already scheduled up to.... here." IMO, scheduling notes to frames during lookahead is _not_ what we want! Tempo changes happen, and if they come from the GUI or from JACK, there's no way that the sequencer can now about it in advance (!), so all the positions of notes scheduled ahead will be wrong! We still need the intermediate priority queue (proposedly it be based on ticks, not ticks + frames as in that dodgy "functor" patch I was sending you last week :-) ) ... > So, I'm trying to totally separate the GUI code from the audio > implementation. To do this I'm creating interfaces and using d-pointers. > I'm trying to only use it where it makes sense. (E.g. using a d-pointer > for Note would be overkill.) I appreciate that intention. Using this technique comes at a price of harder code to read through. But if it serves a purpose (reading here http://en.wikipedia.org/wiki/Opaque_pointer#C.2B.2B clarified this for me a bit) I guess it's justified :-) Cheers -- Jakob ------------------------------------------------------------------------------ _______________________________________________ Hydrogen-devel mailing list Hydrogen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hydrogen-devel
