Am Mon, 9 Mar 2009 14:46:56 -0500 (CDT)
schrieb "Gabriel M. Beddingfield" <[email protected]>:

> 
> On Mon, March 9, 2009 2:17 pm, [email protected] wrote:
> > if you remove so much of this note and instrument stuff the most of
> > note_off funktion from the fx_and sample_fun branch will broke up or the
> > implementation needs a lot of rewrite.
> 
> Look at SeqEvent.h -- the new design includes a note-off implementation. 
> However, I'm also redoing a lot of the sampler.
> 
> > also the current mute group function (trunk) use the single note adsr and
> > instrument adsr implementation.
> 
> Why/how does it use the single-note ADSR?  There's no way to edit those
> parameters... is there?
no not directly. e.g. in note pattern editor note length edit. you can edit the 
note release with the release rotary. it's mostly used for the whole instrument.

see this from sampler.cpp it's e.g. the mute group feature. so the notes will 
tested if
they already played before note push back into playing note queue. if yes and 
together with a active instrument mute group
the m_adsr.release() from the note will activated. and yes you right this is 
not a single note
release, it's the instrument release. so you can edit only one release for all 
notes into
one instrument. but every note get the individual 'm_adsr.release' value. that 
the sampler knows the end of notes with a special length 

in sample process or resample process this note release note->m_adsr.release 
will every time
tested and return 1 if note is ended. and than the note will erased from the 
playing note queue.
 
> 
> > i am not sure, but if this transport will be a base for newer or h2 >0.9.4
> > versions it would
> > be cool if this implementation don't need a rewrite for this well working
> > stuff.
> 
> Just to be clear:  I am not assuming that everyone will love this
> 'transport_redesign' branch, nor am I assuming that it would/could/should
> be merged to trunk.
> 
> However, when we were discussing the transport redesign last year... it
> was implied that it would have consequences on the sampler.  I'm pretty
> sure that when I'm done, most of the meat-and-potatoes code in the sampler
> will remain.
> 
> > ok. and maybe nobody is interested to implement the really useful features
> > from this branch. but if yes, we
> 
> Honestly... I'm not sure what you're doing over there.  :-)  I took a
> brief look around this weekend (because I was considering the impacts on
> the other branches)... but it looks like I'll have to compile the branch
> to see what you're up to.  I'm sure it's good stuff.
> 
> > 8.4.2009 my free time will
> > dramatically reduced. we will get a little daughter in april :-)))))))
> 
> Cool!!  First one??
yes.
> 
> > hooray. so for me,
> > it's can be a problem to do all the work for an implementation to the new
> > transport base.
> 
> I expect to have something that works in about 1 to 3 weeks.  At that
> time, let's all take a look and decide what to do from there.
sounds good.
> 
> Peace,
> Gabriel
> 

------------------------------------------------------------------------------
_______________________________________________
Hydrogen-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hydrogen-devel

Reply via email to