Am Thu, 12 Mar 2009 12:12:04 +0000
schrieb Krzysztof Foltman <[email protected]>:

> [email protected] wrote:
> 
> > 1. don't manage the volume into the sample himself. the best is to use 
> > samples with
> > maximum depth. e.g. max peak -6db, because hydrogen manage the sample 
> > volume by the
> > note velocity and will play the sample which is in this velocity range with 
> > the given
> > note velocity volume. so if you also mange the volume in sample the 
> > velocity curve is
> > a bit unusable (abrupt). i think on this place happens a lot of operating 
> > errors.
> 
> Are you planning any remedy for that?
> 
> I can imagine (sadly, only imagine) a sort of editor that would draw
> amplitude/time curves for different velocities on the same graph,
> marking different layers in different colours. You would then have an
> offset/scale adjustment separately for each layer, to match them visually.
> 
> Just an idea. Don't treat it _too_ seriously :)
but :-D sounds very cool.
> 
> > 2. remove all dc offset from samples and/or add a well balanced high pass. 
> > this
> > reduce the total nerving pop and plop sounds at sample end. a bit the same 
> > than the
> > release problem. dc offset is not 0 and produce every time jump to zero 
> > plop at
> > sample-end. this sounds mostly really bad. also you can lost sample depth 
> > in main
> > mix. if e.g. dc offset will sum by playing together a lot of samples with 
> > the same dc
> > offset.
> 
> Is there a normalize function in sample_fun branch?
not jet. i think since month about a redesign from the fx handling and routing 
in h2. that's why the branch is called fx_...
my idea is to manage a single instrument fx rack like renoise or ardour mange 
this. than my first plan is to add a dc_offset checkbox for each instrument by 
using e.g. the existing ladspa offset remover algorithm.
3 things why i don't realise that for the moment. 1. i have not enough 
programming experience to create such a rack with the complex object handling. 
2. i don't understand really right the existing fx handling :-(  
3. especial for the offset. i don't like the existing ladspa dc_offset remover. 
don't know why, and i an mot s sure, (maybe i am totally wrong here) in my ears 
it sounds that the ladspa dc_offset remover caused frequency dependents phase 
deferrals

wolke.


> 
> Krzysztof
> 
> 
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Hydrogen-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/hydrogen-devel
> 

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Hydrogen-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hydrogen-devel

Reply via email to