Korg's Kaosspad III uses granular processing as far as I know, but haven't
tried one yet.

On 3/11/08, gasp_uleg < uleg2@... > wrote:
>
> well, lets just hope this nice discussion could serve to push a
> little bit of granulation into the physical electronics world and
> that doepfer (or any one else) would soon bring us some cv
> granulation solution of whatever kind, that being deterministic,
> heuristic, stochastic or whatever ic ...
>
> it is quite amazing that with the long time granulation exists no one
> have ever made any comercially avaible module nor stomp box of any
> sort using this great sound technique without computers.
>
> if any one knows about anything of the sort out there, please tell me!
>
> by the way, to patch an output from reaktor must be a joke, heh
> if i had to use a computer then why would i need any external modular
>
> ;)
> best regards
> gaspar
>
> --- In Doepfer_a100@yahoogroups.com <Doepfer_a100%40yahoogroups.com>,
> Denis Gökdag <q-art@...> wrote:
> >
> > one reply to both of your posts :-)
> >
> > i can see your point about a "less access to individual grains,
> more
> > complex results on a single (small) module" approach. generating a
> > typical grain "cloud" would be a lot of modules and patching with
> my
> > approach....but then what i do if i want the "cloud" effect i just
> > patch an output from reaktor or an audio track containing such a
> > texture into the a100. i agree that it would be a lot more
> > comfortable to have this sort of capability in a module,
> > though....ideally there would be both. but if there could only be
> one
> > of the two, i'd opt for the "discrete access" one, as this allows
> for
> > stuff you don't get from an external source.
> >
> >
> > On 07. Mar 2008, at 9:28 PM, gasp_uleg wrote:
> >
> > > -by "density" i mean "distance between grains", which could go
> from
> > > almost total overlap of the grains when a high frecuency clock is
> > > used with long grains.
> > k, that's the way i'd use the term too. see my reply to the
> "voice"
> > issue further down.
> >
> > >
> > > -by saying "dynamics" i simply mean "changes of volume in time" of
> > > each grain (that is the vca+envelope of each grain).
> > >
> > > im not very sure that having so much control of evey single grain
> > > would be so much usefull. i think more of grains as being
> controlable
> > > all togheter, apliyng the polyfonic envelope to all of them at the
> > > same time from inside the dsp but controling the general atack and
> > > release from cv.
> >
> > Well this is true for texture-type granular sounds, but if you
> want
> > to go down the "sequence of extremely short grains" route,
> > essentially building a highly complex, time-varying waveform
> rather
> > than a dense soundscape, control of individual grain fade curves
> > makes for a rather huge difference.
> >
> >
> >
> > >
> > > i'm a bit confused about the "voice" term you use:
> > >
> > > i understand a "granular generator" as being a "granular
> processor"
> > > intimatelly associated to a sample player or "source file" as you
> > > call it.
> > basically a "grain" is the same as one voice of a sampler playing
> > back a specific section of a larger sample ("source file"). If i.e.
> 2
> > grains overlap, you technically need to play back two voices, or
> > "streams". In more complex, "meta-style" grain generators like the
> > reaktor grain cloud this fact is simply hidden, as this technical
> > aspect is not of any interest by itself in the context of
> generating
> > a "cloud", all you want to know there is how "dense" the result
> will
> > be (in whichever way the module achieves this). But when you
> *build*
> > such a module in hardware, it is, as every grain needs to be
> treated
> > as a separate "entity" in memory anyway (thats just the way the
> > method works).....so as you already have the grains available
> > seperately you might as well make them have their individual
> outputs
> > and individual parameters to better fit the pradigm of a modular
> > analog synthesizer. I call this combination of parameter controls,
> > one playback "stream" and a set of outputs a "voice". In my
> proposal
> > there would be four of these "voices", effectively making it
> possible
> > for four grains to overlap at any one time. This would make the
> > "cloud" type application somewhat possible (though not very
> dense),
> > while making lots of really cool resonation, electrification,
> > glitching, noisy, scraping pulsed digital stuff possible :-)
> >
> >
> >
> > >
> > > being able to select diferent files for that "source file" doesn't
> > > mean having several voices. it's allways the same single voice but
> > > having a diferent basic sound.
> >
> > Absolutely. Best example is CDPs "brassage(old)" for this kinda
> > thing, or waveform software's "amber-x". Even reaktors grain cloud
> > can select a different source file per grain triggering event. BUT
> > the reason i recommend having one fixed sample/source file for
> each
> > voice is quite simple: this way i can keep track (and thus
> control)
> > of which source file is being used by which grain, as a eurorack
> > module will not have a display telling me which file is currently
> > being referenced by which voice. This is both of use on stage (or
> in
> > any other "i gotta know my stuff"-performance situation) as well
> as
> > it (ever so slightly) slightly reduces DSP-load (no switching
> between
> > different address spaces in memory) and makes constructing
> specific
> > results more straight-forward and manageable. And you can still
> > reference a variety of source files by defining which voice plays
> at
> > which time and possibly using more than one module for more than
> four
> > source files simultaneously. But then tha's just me, i don't mind
> > buying multiple modules, i even went and bought two vocoder core
> > systems for midi-automated stereo filterbanks ;-)
> >
> > In general it would be smart to keep a *realtime*, near-to-zero-
> > latency granular processor as dumb (or "mechanical"/"close to
> > hardware" )as possible, because every additional layer of software
> > makes timing more and more inaccurate (or at least it steadily
> > becomes more challenging to code the algorithm in such a way that
> the
> > order of things is right) on financially viable DSP setups. If
> you'd
> > want to do it perfect, you'd build it discreetly with counter-ICs
> for
> > memory pointers and only supply these with offsets and reset
> values
> > generated in higher level software as these values are only
> generated
> > once per grain. You'd simply clock the playback and D/As off an on-
> > board or external VC-clock (like in the BBD), skipping the common
> > system clock/sample rate and hence avoiding aliasing when doing FM
> > (as you'd do this at the clock, not in the grain module's memory).
> > BUT this approach would basically draw tons of current and require
> a
> > lot of ICs and thus a rather complex board layout etc, making it
> > rather unaffordable and large ;-)
> >
> >
> > >
> > > the grains are "riden" in realtime from the basic "source file" at
> > > the point of a "moving cursor" (sort of). (a totally agree that an
> > > external lag processor could be used if the "cursor" is
> controlable
> > > via external cv)
> > >
> > > the audio signal "contained" in a grain is constantly changing
> > > depending on where of the "source file" the grain is being taken
> and
> > > depending on how much feedback+delay is aplied to the grains.
> > >
> > > only when a "freeze" function is used the grain's audio content is
> > > totally stabilized.
> > correct except for that feedback+delay+"freeze"is typically not
> found
> > in *generators* but in *processors*, because:
> >
> >
> > >
> > > it makes absolute sense to be able to refeed the grains with their
> > > output signal with some possible delay so timbre can be alterated
> in
> > > many ways. if pitch pitch changes are aplied to the grains or to
> the
> > > main "source file" many great sounds can be obtained (from pitch
> > > shifts to vapourous sounds, time streching, reverbs or infinite
> kinds
> > > of digital glitch effects)
> >
> > a *generator* takes grains from files, a *processor* takes grains
> > from a writable memory, as in a delay module or pitch-shifter.
> While
> > the memory content is static in case of a generator (and you'd
> want
> > it to be to be able to take the "colour" of a *specific* source
> file
> > and bring it in to your new sound), the memory content of a
> > *processor* is dynamic....the latter could be triggered to record
> > from an input (including a delayed and fed-back version of the
> > processor's output) and would reference *this* when generating
> > grains, instead of a file. A "freeze" function simply sets this
> > memory to be un-writable, so it effectively turns into a static
> > content as you would have hwen using a file. You wouldn't be able
> to
> > have repeatable and clearly determined results with a *processor*,
> > and you wouldn't have the organic uncertainty with the
> > *generator*....hence the differentiation between the two, as they
> are
> > used for quite different applications. One is deterministic/
> > constructivistic, one is heuristic.
> >
> > I fully agree that delayed feedback is of great use in a
> *processor*.
> >
> > In my suggested module the *processor*-behaviour could simply be
> > implemented with a memory-writer add-on module (except for the
> > feedback, which you would have to patch manually).....all this add-
> on
> > would do is provide the generator module with sound that the mem-
> > writer records, which the generator would use instead of a loaded
> > file. so you'd swap the static file for a writable memory. in this
> > case creating a "delay" is simply creating an offset between the
> > writing pointer's and the reading pointer's position (which is
> > exactly how a delay is implemented). "Freezing" would simply be
> > achieved by blocking the "record" control (with an inverter and an
> > AND gate, to be specific ;-) )
> >
> > l8a,
> > d
> >
>
>
>


[Non-text portions of this message have been removed]