Doepfer

yes, indeed.
i have been lost in this detailed discussion and you
guys (D&G) seem to really dig deep...
so, a granular proccesor/generator module would be
great.    :-)
best regards,
Bakis.


--- David Salter <david.salter@reuters.com> wrote:

> D&G,
>  
> How about you guys getting together, producing a
> spec and building it so the rest of can enjoy the
> pleasures of granular synthesis in a modular :o)
>  
>  
>  
> David Salter
> Senior Consultant
> PSG 
> 
> Reuters Messaging:
> david.salter.reuters.com@reuters.net
> (t) +44 (0)20 7542 2402 | (m) 07990562402 | (f)
> 52699 
> 
> Get the latest news at Reuters.com
> <http://www.reuters.com/> 
> 
>  
> 
> ________________________________
> 
> From: Doepfer_a100@yahoogroups.com
> [mailto:Doepfer_a100@yahoogroups.com] On Behalf Of
> Denis Gökdag
> Sent: 07 March 2008 14:11
> To: Doepfer_a100@yahoogroups.com
> Subject: Re: [Doepfer_a100] Re: granular processor &
> generato
> 
> 
> 
> >
> > grains are not fixed samples, they are bits of
> samples put togheter or
> > more correctly: a long sample is smashed into
> smaller samples 
> > (grains).
> >
> > grains parameters (position, pitch, lenght,
> density and dynamics) 
> > should
> > be controllable independently from those of the
> main sample (loop 
> > points,
> > pich/speed, direction...)
> 
> well i do not see where this is any different from
> what i wrote, 
> sorry if i made my points in a too involved or
> technical way; i've 
> been thinking about making a grain module for quite
> a while but so 
> far have been lacking the time and infrastructure to
> do, hence the 
> dsp-nerd-style ;-)
> it i will use the term "source file" instead of
> "sample" from now 
> on to make clearer what i am saying. there are two
> main differences 
> between what you wrote and what i wrote:
> 
> a) you introduce the idea of selecting between
> multiple "source 
> files" *per voice*, while i was suggesting using one
> source file per 
> voice. your approach would be more "intuitively
> shaping semi-random 
> results", while mine would be more "constructivist".
> i do like the 
> idea of selecting a source file per CV, but it could
> be done by 
> switching/fading between the individual outputs of
> the voices with an 
> a152 or 144/135 combo for example....lowering the
> strain on the DSP 
> and giving more acces to what happens with every
> single grain.
> 
> b) you're more into "meta attributes", like
> "density" and 
> "dynamics" (which are not clearly defined, and could
> technically be 
> interpreted as "average # of grains started per time
> unit"/"average 
> amount of grains overlapping at any given time" and
> "amplitude 
> envelope within a grain"/"time varying amplitude
> scaling of whole 
> grains".....so we're basically talking about
> statistics and sequencer- 
> like terms here), i'm more into "discrete control"
> and leaving as 
> many functions outside the module as possible, again
> lowering the 
> workload on the DSP and giving access to every
> single grain. call me 
> a control freak but i much prefer to be able to
> process every single 
> grain independently in my a100 and leave the
> random/statistic 
> distribution stuff to other dedicated modules :-)
> 
> I may be wrong, but i believe it is important to
> leave the processor 
> load as low as possible if you want to both have
> realtime control of 
> all parameters at audio rate (where it maakes sense)
> *and* a good 
> audio quality. In the module i proposed, we're
> already lloking at the 
> following operations per grain:
> 
> - evaluate all A/D inputs and write their values to
> memory (to have 
> the data needed for all following operations)
> - read from memory location in source file specified
> by input parameters
> - perform real-time interpolating sample rate
> conversion (for the 
> transposition)
> - create from input parameters and read from two
> look-up tables for 
> the fade curves
> - multiply sample values with that data for the
> fades
> - possibly crossfade into next grain (which means
> that all the above 
> operations will have to be executed *before* the
> next grain arrives, 
> which might be 1/samplerate seconds later only...AND
> for the 
> following grain as well.)
> - write audio to D/A buffer, write data to control
> output buffers.
> 
> I think this already is quite a lot of work for a
> DSP, especially if 
> you take into account that the sample rate would
> probably have to be 
> at least 88.2khz or higher to avoid aliasing when
> performing audio- 
> rate FM on the grains, as the sidebands introduced
> will easily go 
> above the nyquist frequency on most material. And
> you probably don't 
> want such a module to have a latency of more than
> 10ms (and even that 
> would be a lot for a module in an analog setup).
> >
> > - a cv lag processor for the position pointer
> would allow to smooth 
> > the
> > transition of granulation travelling thru the long
> sample
> simply use a lag processor before the cv input. you
> don't want to 
> switch position while a grain is playing, as that
> either introduces 
> signal discontinuities aka clicks'npops, OR requires
> a lot of 
> interpolation going on all the time.
> >
> > - a clock/trig input would control the density of
> grains
> >
> > - a gate input would trigger the playback of the
> grains
> these two exclude each other. you *either* have a
> statistical 
> distribution aka "density" (which is more or less
> random, 
> controllable from a fixed rate to noise sampled at a
> clock rate 
> specified by "density") OR you trigger an individual
> grain at a 
> specified point in time. the only way to mix these
> is to force a 
> grain on grain trigger, overriding the automatic
> triggering set by 
> the "density" parameter.....but you could simply
> switch between a 
> controlled trigger source and digital noise (a117)
> before the trigger 
> input.
> also no *gate" is required in the setting you
> describe, just a 
> *trigger* (as the length of the grain is defined by
> its own parameter)
> 
> >
> > - a cv input to control grains pitch
> >
> > - a cv input to control main sample's pitch
> These both affect the same parameter and thus one is
> redundant.
> >
> > - a cv input for atack time of the grains
> >
> 
=== message truncated ===


Bakis Sirros - Parallel Worlds / Interconnected / Memory Geist
[Doepfer_a100] group owner
http://www.parallel-worlds-music.com
http://www.myspace.com/parallelworldsmusic
http://www.myspace.com/interconnectedmusic
http://www.myspace.com/memorygeist
http://www.DiN.org.uk
http://www.musicamaximamagnetica.com
http://www.shimarecords.co.uk
http://www.rubber.gr
Athens-Greece


      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping