Loading ...
Sorry, an error occurred while loading the content.

Re: [Doepfer_a100] granular processor & generato

Expand Messages
  • Korhan Erel
    Can several A-112s be used to construct a simple granular synth, with the A-112s in wavetable mode? Each A-112 would represent a grain going into a filter and
    Message 1 of 28 , Mar 2, 2008
    • 0 Attachment
      Can several A-112s be used to construct a simple granular synth, with the
      A-112s in wavetable mode? Each A-112 would represent a grain going into a
      filter and then into a VCA, shaped by a ADSR? I guess a 4 grain synth would
      cost a small fortune, but it's probably worth it.

      On 2/17/08, gasp_uleg <uleg2@...> wrote:
      >
      > i am a fanatic of modular concept but i never had the money to build
      > the gigantic modular of my dreams so i went into virtual and i
      > specialized myself into Reaktor, where i've found everythink i ever
      > needed.
      >
      > but the thing is that i deeply hate to use computer in concerts so
      > now i'm trying to rebuild my reaktor setups into a totally physical
      > way. with A100 and the other modulars everything i need can perfectly
      > be done EXCEPT granulation which has become my favourite sound
      > generator and modifier latelly.
      >
      > i think not only granular cloud-delay processing is interesting. also
      > a granular sample player would be an amazing module.
      >
      > i don't know much about DSP but if people like clavia have been able
      > to fit all what is inside a micromodular or if pedal manufacturers
      > are now using DSP for their new guitar pedals, it must be possible to
      > find some cheap DSP technology to be fit into a vc modular format.
      >
      > of course i understand development and technical expertise is very
      > diferent for digital stuff than
      > for purelly analog electronics design but i'm sure ther are many
      > young geniuses running out there with their nice diplomas in "very
      > really complicated informatics" just willing to be emploid to program
      > the complicated DSP algorithms for our modulars.
      >
      >
      >


      [Non-text portions of this message have been removed]
    • Korhan Erel
      Since the A-112s cannot toggle between record and play, my idea of the granular synthesis can work only on prerecorded samples (assuming it was a good/feasible
      Message 2 of 28 , Mar 4, 2008
      • 0 Attachment
        Since the A-112s cannot toggle between record and play, my idea of the
        granular synthesis can work only on prerecorded samples (assuming it was a
        good/feasible idea to start with)

        On 3/3/08, Korhan Erel <listekutusu@...> wrote:
        >
        > Can several A-112s be used to construct a simple granular synth, with the
        > A-112s in wavetable mode? Each A-112 would represent a grain going into a
        > filter and then into a VCA, shaped by a ADSR? I guess a 4 grain synth would
        > cost a small fortune, but it's probably worth it.
        >
        > On 2/17/08, gasp_uleg <uleg2@...> wrote:
        > >
        > > i am a fanatic of modular concept but i never had the money to build
        > > the gigantic modular of my dreams so i went into virtual and i
        > > specialized myself into Reaktor, where i've found everythink i ever
        > > needed.
        > >
        > > but the thing is that i deeply hate to use computer in concerts so
        > > now i'm trying to rebuild my reaktor setups into a totally physical
        > > way. with A100 and the other modulars everything i need can perfectly
        > > be done EXCEPT granulation which has become my favourite sound
        > > generator and modifier latelly.
        > >
        > > i think not only granular cloud-delay processing is interesting. also
        > > a granular sample player would be an amazing module.
        > >
        > > i don't know much about DSP but if people like clavia have been able
        > > to fit all what is inside a micromodular or if pedal manufacturers
        > > are now using DSP for their new guitar pedals, it must be possible to
        > > find some cheap DSP technology to be fit into a vc modular format.
        > >
        > > of course i understand development and technical expertise is very
        > > diferent for digital stuff than
        > > for purelly analog electronics design but i'm sure ther are many
        > > young geniuses running out there with their nice diplomas in "very
        > > really complicated informatics" just willing to be emploid to program
        > > the complicated DSP algorithms for our modulars.
        > >
        > >
        > >
        >
        >


        [Non-text portions of this message have been removed]
      • partlydrone
        i realise this is slightly unhelpful half advice but i have a very clear memory of reading - somewhere - instructions on how to install gate control of record
        Message 3 of 28 , Mar 4, 2008
        • 0 Attachment
          i realise this is slightly unhelpful half advice but i have a very
          clear memory of reading - somewhere - instructions on how to install
          gate control of record on an a112. it might even have been here.

          soldering gate control of knobs isnt as bad as you think, you're not
          tinkering with the circuits, just the wires going to the knobs. if
          you've not done it before just practise for a couple of hours on some
          crud (and if you're like a professional repairman then my apologies...)



          --- In Doepfer_a100@yahoogroups.com, "Korhan Erel" <listekutusu@...>
          wrote:
          >
          > Since the A-112s cannot toggle between record and play, my idea of the
          > granular synthesis can work only on prerecorded samples (assuming it
          was a
          > good/feasible idea to start with)
          >
          > On 3/3/08, Korhan Erel <listekutusu@...> wrote:
          > >
          > > Can several A-112s be used to construct a simple granular synth,
          with the
          > > A-112s in wavetable mode? Each A-112 would represent a grain going
          into a
          > > filter and then into a VCA, shaped by a ADSR? I guess a 4 grain
          synth would
          > > cost a small fortune, but it's probably worth it.
          > >
          > > On 2/17/08, gasp_uleg <uleg2@...> wrote:
          > > >
          > > > i am a fanatic of modular concept but i never had the money to
          build
          > > > the gigantic modular of my dreams so i went into virtual and i
          > > > specialized myself into Reaktor, where i've found everythink i ever
          > > > needed.
          > > >
          > > > but the thing is that i deeply hate to use computer in concerts so
          > > > now i'm trying to rebuild my reaktor setups into a totally physical
          > > > way. with A100 and the other modulars everything i need can
          perfectly
          > > > be done EXCEPT granulation which has become my favourite sound
          > > > generator and modifier latelly.
          > > >
          > > > i think not only granular cloud-delay processing is interesting.
          also
          > > > a granular sample player would be an amazing module.
          > > >
          > > > i don't know much about DSP but if people like clavia have been able
          > > > to fit all what is inside a micromodular or if pedal manufacturers
          > > > are now using DSP for their new guitar pedals, it must be
          possible to
          > > > find some cheap DSP technology to be fit into a vc modular format.
          > > >
          > > > of course i understand development and technical expertise is very
          > > > diferent for digital stuff than
          > > > for purelly analog electronics design but i'm sure ther are many
          > > > young geniuses running out there with their nice diplomas in "very
          > > > really complicated informatics" just willing to be emploid to
          program
          > > > the complicated DSP algorithms for our modulars.
          > > >
          > > >
          > > >
          > >
          > >
          >
          >
          > [Non-text portions of this message have been removed]
          >
        • Carlos
          Granular synthesis uses anywhere from a few dozen grains to thousands of them.being able to change the number of grains is essential to get a good variety of
          Message 4 of 28 , Mar 4, 2008
          • 0 Attachment
            Granular synthesis uses anywhere from a few dozen grains to thousands of them.being able to change the number of grains is essential to get a good variety of sounds, I don't think a few fixed grains would do the trick


            --- In Doepfer_a100@yahoogroups.com, "Korhan Erel" <listekutusu@...> wrote:
            >
            > Since the A-112s cannot toggle between record and play, my idea of the
            > granular synthesis can work only on prerecorded samples (assuming it was a
            > good/feasible idea to start with)
            >
            > On 3/3/08, Korhan Erel <listekutusu@...> wrote:
            > >
            > > Can several A-112s be used to construct a simple granular synth, with the
            > > A-112s in wavetable mode? Each A-112 would represent a grain going into a
            > > filter and then into a VCA, shaped by a ADSR? I guess a 4 grain synth would
            > > cost a small fortune, but it's probably worth it.
            > >
            > > On 2/17/08, gasp_uleg <uleg2@...> wrote:
            > > >
            > > > i am a fanatic of modular concept but i never had the money to build
            > > > the gigantic modular of my dreams so i went into virtual and i
            > > > specialized myself into Reaktor, where i've found everythink i ever
            > > > needed.
            > > >
            > > > but the thing is that i deeply hate to use computer in concerts so
            > > > now i'm trying to rebuild my reaktor setups into a totally physical
            > > > way. with A100 and the other modulars everything i need can perfectly
            > > > be done EXCEPT granulation which has become my favourite sound
            > > > generator and modifier latelly.
            > > >
            > > > i think not only granular cloud-delay processing is interesting. also
            > > > a granular sample player would be an amazing module.
            > > >
            > > > i don't know much about DSP but if people like clavia have been able
            > > > to fit all what is inside a micromodular or if pedal manufacturers
            > > > are now using DSP for their new guitar pedals, it must be possible to
            > > > find some cheap DSP technology to be fit into a vc modular format.
            > > >
            > > > of course i understand development and technical expertise is very
            > > > diferent for digital stuff than
            > > > for purelly analog electronics design but i'm sure ther are many
            > > > young geniuses running out there with their nice diplomas in "very
            > > > really complicated informatics" just willing to be emploid to program
            > > > the complicated DSP algorithms for our modulars.
            > > >
            > > >
            > > >
            > >
            > >
            >
            >
            > [Non-text portions of this message have been removed]
            >
          • Korhan Erel
            Hi Carlos, As I said in my earlier mail that even a 4-grain system would cost a fortune. On the other hand, a module that includes a DSP programmed to do
            Message 5 of 28 , Mar 5, 2008
            • 0 Attachment
              Hi Carlos,

              As I said in my earlier mail that even a 4-grain system would cost a
              fortune. On the other hand, a module that includes a DSP programmed to do
              granular synthesis would also cost a lot, given that it will have to be a
              powerful DSP to handle a high number of grains. It would also have to
              include features like slew, filter, pitch shifting, amp, panning, etc, as
              you would not be able to process grains separately with modules.

              Korhan


              On 3/5/08, Carlos <bushwick@...> wrote:
              >
              > Granular synthesis uses anywhere from a few dozen grains to thousands of
              > them.being able to change the number of grains is essential to get a good
              > variety of sounds, I don't think a few fixed grains would do the trick
              >
              > --- In Doepfer_a100@yahoogroups.com <Doepfer_a100%40yahoogroups.com>,
              > "Korhan Erel" <listekutusu@...> wrote:
              > >
              > > Since the A-112s cannot toggle between record and play, my idea of the
              > > granular synthesis can work only on prerecorded samples (assuming it was
              > a
              > > good/feasible idea to start with)
              > >
              > > On 3/3/08, Korhan Erel <listekutusu@...> wrote:
              > > >
              > > > Can several A-112s be used to construct a simple granular synth, with
              > the
              > > > A-112s in wavetable mode? Each A-112 would represent a grain going
              > into a
              > > > filter and then into a VCA, shaped by a ADSR? I guess a 4 grain synth
              > would
              > > > cost a small fortune, but it's probably worth it.
              > > >
              > > > On 2/17/08, gasp_uleg <uleg2@...> wrote:
              > > > >
              > > > > i am a fanatic of modular concept but i never had the money to build
              > > > > the gigantic modular of my dreams so i went into virtual and i
              > > > > specialized myself into Reaktor, where i've found everythink i ever
              > > > > needed.
              > > > >
              > > > > but the thing is that i deeply hate to use computer in concerts so
              > > > > now i'm trying to rebuild my reaktor setups into a totally physical
              > > > > way. with A100 and the other modulars everything i need can
              > perfectly
              > > > > be done EXCEPT granulation which has become my favourite sound
              > > > > generator and modifier latelly.
              > > > >
              > > > > i think not only granular cloud-delay processing is interesting.
              > also
              > > > > a granular sample player would be an amazing module.
              > > > >
              > > > > i don't know much about DSP but if people like clavia have been able
              > > > > to fit all what is inside a micromodular or if pedal manufacturers
              > > > > are now using DSP for their new guitar pedals, it must be possible
              > to
              > > > > find some cheap DSP technology to be fit into a vc modular format.
              > > > >
              > > > > of course i understand development and technical expertise is very
              > > > > diferent for digital stuff than
              > > > > for purelly analog electronics design but i'm sure ther are many
              > > > > young geniuses running out there with their nice diplomas in "very
              > > > > really complicated informatics" just willing to be emploid to
              > program
              > > > > the complicated DSP algorithms for our modulars.
              > > > >
              > > > >
              > > > >
              > > >
              > > >
              > >
              > >
              > > [Non-text portions of this message have been removed]
              > >
              >
              >
              >


              [Non-text portions of this message have been removed]
            • Denis Gökdag
              Weeeelllll..... there is no reason a DSP-based granular module should not be able to output n grains to n outputs. Grains are computed as separate entities and
              Message 6 of 28 , Mar 5, 2008
              • 0 Attachment
                Weeeelllll.....

                there is no reason a DSP-based granular module should not be able to
                output n grains to n outputs. Grains are computed as separate
                entities and get summed just before the output. So skipping the
                summing stage and replacing it with n outputs would not be such an
                issue. It would raise the price of a module because you'd use more D/
                A's, though. So filter, amp and panning could all be done outside
                such a module, provided the module outputs trigger data etc for each
                grain.

                What would really make the whole thing rely on a high-powered DSP (or
                more than one) is if you want to be able to modulate transposition/
                position etc at audio rate....IMHO a must in a modular (can you spell
                "control rate vs audio rate" in reaktor? ugh)

                I personally think that an 8 or 16 grain system would be sufficient,
                provided there was a way to link more than one in an "intelligent"
                manner.

                Now what i think is the main issue with a module like this is: what
                control philosophy does it use? You can either have dedicated control
                of every grain or use some sort of "structural logic" that the module
                itself applies (aka "grain density" instead of separate grain
                triggers, "pitch jitter" instead of CV control of every grain pitch,
                "density evolution" instead of variable rate grain trigger signal). I
                personally think that in a modular system you'd want the discrete
                version, if i want meta-control only i can use reaktor or anything
                else.....the cool thing is to have the grain stuff *integrate*
                perfectly into the system, and for that you definitely need access to
                the individual grain's parameters. Now the downside of this is that
                it would be a large and expensive module, and that doing some of the
                standard meta-attribute stuff would take a lot of patching. Maybe
                here there would be a good opportunity to create some structured data
                modules.....;-)


                Now imagine what you could do with a grain thang at audio rate....use
                an audio rate pulse for the triggering of a grain, clock a sequencer
                with the same pulse and have that select playback position and grain
                transposition (or grain duration) of the grain thang, effectively
                getting a waveform that is F*N in length ( F being pulse frequency
                expressed in seconds, N being number of steps in the sequence). And
                we're just talking about grain #1 here :-)


                my 2 ct

                d



                On 05. Mar 2008, at 9:12 AM, Korhan Erel wrote:

                > Hi Carlos,
                >
                > As I said in my earlier mail that even a 4-grain system would cost a
                > fortune. On the other hand, a module that includes a DSP programmed
                > to do
                > granular synthesis would also cost a lot, given that it will have
                > to be a
                > powerful DSP to handle a high number of grains. It would also have to
                > include features like slew, filter, pitch shifting, amp, panning,
                > etc, as
                > you would not be able to process grains separately with modules.
                >
                > Korhan
                >
                > On 3/5/08, Carlos <bushwick@...> wrote:
                > >
                > > Granular synthesis uses anywhere from a few dozen grains to
                > thousands of
                > > them.being able to change the number of grains is essential to
                > get a good
                > > variety of sounds, I don't think a few fixed grains would do the
                > trick
                > >
                > > --- In Doepfer_a100@yahoogroups.com <Doepfer_a100%
                > 40yahoogroups.com>,
                > > "Korhan Erel" <listekutusu@...> wrote:
                > > >
                > > > Since the A-112s cannot toggle between record and play, my idea
                > of the
                > > > granular synthesis can work only on prerecorded samples
                > (assuming it was
                > > a
                > > > good/feasible idea to start with)
                > > >
                > > > On 3/3/08, Korhan Erel <listekutusu@...> wrote:
                > > > >
                > > > > Can several A-112s be used to construct a simple granular
                > synth, with
                > > the
                > > > > A-112s in wavetable mode? Each A-112 would represent a grain
                > going
                > > into a
                > > > > filter and then into a VCA, shaped by a ADSR? I guess a 4
                > grain synth
                > > would
                > > > > cost a small fortune, but it's probably worth it.
                > > > >
                > > > > On 2/17/08, gasp_uleg <uleg2@...> wrote:
                > > > > >
                > > > > > i am a fanatic of modular concept but i never had the money
                > to build
                > > > > > the gigantic modular of my dreams so i went into virtual and i
                > > > > > specialized myself into Reaktor, where i've found
                > everythink i ever
                > > > > > needed.
                > > > > >
                > > > > > but the thing is that i deeply hate to use computer in
                > concerts so
                > > > > > now i'm trying to rebuild my reaktor setups into a totally
                > physical
                > > > > > way. with A100 and the other modulars everything i need can
                > > perfectly
                > > > > > be done EXCEPT granulation which has become my favourite sound
                > > > > > generator and modifier latelly.
                > > > > >
                > > > > > i think not only granular cloud-delay processing is
                > interesting.
                > > also
                > > > > > a granular sample player would be an amazing module.
                > > > > >
                > > > > > i don't know much about DSP but if people like clavia have
                > been able
                > > > > > to fit all what is inside a micromodular or if pedal
                > manufacturers
                > > > > > are now using DSP for their new guitar pedals, it must be
                > possible
                > > to
                > > > > > find some cheap DSP technology to be fit into a vc modular
                > format.
                > > > > >
                > > > > > of course i understand development and technical expertise
                > is very
                > > > > > diferent for digital stuff than
                > > > > > for purelly analog electronics design but i'm sure ther are
                > many
                > > > > > young geniuses running out there with their nice diplomas
                > in "very
                > > > > > really complicated informatics" just willing to be emploid to
                > > program
                > > > > > the complicated DSP algorithms for our modulars.
                > > > > >
                > > > > >
                > > > > >
                > > > >
                > > > >
                > > >
                > > >
                > > > [Non-text portions of this message have been removed]
                > > >
                > >
                > >
                > >
                >
                > [Non-text portions of this message have been removed]
                >
                >
                >



                [Non-text portions of this message have been removed]
              • David Salter
                hi Denis, I love granular systems and you have described a very desirable module. I agree that you need as much control as possible and that would indeed make
                Message 7 of 28 , Mar 5, 2008
                • 0 Attachment
                  hi Denis,

                  I love granular systems and you have described a very desirable module. I agree that you need as much control as possible and that would indeed make such a module expensive and large as I would prefer 16 grains but would settle on 8.

                  If only :o)

                  David

                  David Salter
                  Senior Consultant
                  PSG

                  Reuters Messaging: david.salter.reuters.com@...
                  (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: 05 March 2008 13:33
                  To: Doepfer_a100@yahoogroups.com
                  Subject: Re: [Doepfer_a100] Re: granular processor & generato



                  Weeeelllll.....

                  there is no reason a DSP-based granular module should not be able to
                  output n grains to n outputs. Grains are computed as separate
                  entities and get summed just before the output. So skipping the
                  summing stage and replacing it with n outputs would not be such an
                  issue. It would raise the price of a module because you'd use more D/
                  A's, though. So filter, amp and panning could all be done outside
                  such a module, provided the module outputs trigger data etc for each
                  grain.

                  What would really make the whole thing rely on a high-powered DSP (or
                  more than one) is if you want to be able to modulate transposition/
                  position etc at audio rate....IMHO a must in a modular (can you spell
                  "control rate vs audio rate" in reaktor? ugh)

                  I personally think that an 8 or 16 grain system would be sufficient,
                  provided there was a way to link more than one in an "intelligent"
                  manner.

                  Now what i think is the main issue with a module like this is: what
                  control philosophy does it use? You can either have dedicated control
                  of every grain or use some sort of "structural logic" that the module
                  itself applies (aka "grain density" instead of separate grain
                  triggers, "pitch jitter" instead of CV control of every grain pitch,
                  "density evolution" instead of variable rate grain trigger signal). I
                  personally think that in a modular system you'd want the discrete
                  version, if i want meta-control only i can use reaktor or anything
                  else.....the cool thing is to have the grain stuff *integrate*
                  perfectly into the system, and for that you definitely need access to
                  the individual grain's parameters. Now the downside of this is that
                  it would be a large and expensive module, and that doing some of the
                  standard meta-attribute stuff would take a lot of patching. Maybe
                  here there would be a good opportunity to create some structured data
                  modules.....;-)

                  Now imagine what you could do with a grain thang at audio rate....use
                  an audio rate pulse for the triggering of a grain, clock a sequencer
                  with the same pulse and have that select playback position and grain
                  transposition (or grain duration) of the grain thang, effectively
                  getting a waveform that is F*N in length ( F being pulse frequency
                  expressed in seconds, N being number of steps in the sequence). And
                  we're just talking about grain #1 here :-)

                  my 2 ct

                  d

                  On 05. Mar 2008, at 9:12 AM, Korhan Erel wrote:

                  > Hi Carlos,
                  >
                  > As I said in my earlier mail that even a 4-grain system would cost a
                  > fortune. On the other hand, a module that includes a DSP programmed
                  > to do
                  > granular synthesis would also cost a lot, given that it will have
                  > to be a
                  > powerful DSP to handle a high number of grains. It would also have to
                  > include features like slew, filter, pitch shifting, amp, panning,
                  > etc, as
                  > you would not be able to process grains separately with modules.
                  >
                  > Korhan
                  >
                  > On 3/5/08, Carlos <bushwick@... <mailto:bushwick%40gmail.com> > wrote:
                  > >
                  > > Granular synthesis uses anywhere from a few dozen grains to
                  > thousands of
                  > > them.being able to change the number of grains is essential to
                  > get a good
                  > > variety of sounds, I don't think a few fixed grains would do the
                  > trick
                  > >
                  > > --- In Doepfer_a100@yahoogroups.com <mailto:Doepfer_a100%40yahoogroups.com> <Doepfer_a100%
                  > 40yahoogroups.com>,
                  > > "Korhan Erel" <listekutusu@...> wrote:
                  > > >
                  > > > Since the A-112s cannot toggle between record and play, my idea
                  > of the
                  > > > granular synthesis can work only on prerecorded samples
                  > (assuming it was
                  > > a
                  > > > good/feasible idea to start with)
                  > > >
                  > > > On 3/3/08, Korhan Erel <listekutusu@...> wrote:
                  > > > >
                  > > > > Can several A-112s be used to construct a simple granular
                  > synth, with
                  > > the
                  > > > > A-112s in wavetable mode? Each A-112 would represent a grain
                  > going
                  > > into a
                  > > > > filter and then into a VCA, shaped by a ADSR? I guess a 4
                  > grain synth
                  > > would
                  > > > > cost a small fortune, but it's probably worth it.
                  > > > >
                  > > > > On 2/17/08, gasp_uleg <uleg2@...> wrote:
                  > > > > >
                  > > > > > i am a fanatic of modular concept but i never had the money
                  > to build
                  > > > > > the gigantic modular of my dreams so i went into virtual and i
                  > > > > > specialized myself into Reaktor, where i've found
                  > everythink i ever
                  > > > > > needed.
                  > > > > >
                  > > > > > but the thing is that i deeply hate to use computer in
                  > concerts so
                  > > > > > now i'm trying to rebuild my reaktor setups into a totally
                  > physical
                  > > > > > way. with A100 and the other modulars everything i need can
                  > > perfectly
                  > > > > > be done EXCEPT granulation which has become my favourite sound
                  > > > > > generator and modifier latelly.
                  > > > > >
                  > > > > > i think not only granular cloud-delay processing is
                  > interesting.
                  > > also
                  > > > > > a granular sample player would be an amazing module.
                  > > > > >
                  > > > > > i don't know much about DSP but if people like clavia have
                  > been able
                  > > > > > to fit all what is inside a micromodular or if pedal
                  > manufacturers
                  > > > > > are now using DSP for their new guitar pedals, it must be
                  > possible
                  > > to
                  > > > > > find some cheap DSP technology to be fit into a vc modular
                  > format.
                  > > > > >
                  > > > > > of course i understand development and technical expertise
                  > is very
                  > > > > > diferent for digital stuff than
                  > > > > > for purelly analog electronics design but i'm sure ther are
                  > many
                  > > > > > young geniuses running out there with their nice diplomas
                  > in "very
                  > > > > > really complicated informatics" just willing to be emploid to
                  > > program
                  > > > > > the complicated DSP algorithms for our modulars.
                  > > > > >
                  > > > > >
                  > > > > >
                  > > > >
                  > > > >
                  > > >
                  > > >
                  > > > [Non-text portions of this message have been removed]
                  > > >
                  > >
                  > >
                  > >
                  >
                  > [Non-text portions of this message have been removed]
                  >
                  >
                  >

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






                  This email was sent to you by Reuters, the global news and information company.
                  To find out more about Reuters visit www.about.reuters.com

                  Any views expressed in this message are those of the individual sender,
                  except where the sender specifically states them to be the views of Reuters Limited.

                  Reuters Limited is part of the Reuters Group of companies, of which Reuters Group PLC is the ultimate parent company.
                  Reuters Group PLC - Registered office address: The Reuters Building, South Colonnade, Canary Wharf, London E14 5EP, United Kingdom
                  Registered No: 3296375
                  Registered in England and Wales



                  [Non-text portions of this message have been removed]
                • Korhan Erel
                  So it boils down to what I say. Modular digital/analog granular synthesis is expensive! :-) A work around to this would be to get a multi-out sound card (say 8
                  Message 8 of 28 , Mar 5, 2008
                  • 0 Attachment
                    So it boils down to what I say. Modular digital/analog granular synthesis is
                    expensive! :-)

                    A work around to this would be to get a multi-out sound card (say 8 outs),
                    send a grain to each output (easily done with PD, Max, LiSa, etc.) and
                    connect those outputs to modules... This way, only the source audio would be
                    digital (as it would be with a DSP module) and the processing would be
                    analog.

                    I do have such an audio interface but don't have enough modules to try it
                    out. Perhaps someone here who owns those monster cases full of modules
                    could?

                    Denis, are you Turkish by any chance? Your last name is Turkish, it seems.

                    Best,

                    Korhan



                    On 3/5/08, David Salter <david.salter@...> wrote:
                    >
                    > hi Denis,
                    >
                    > I love granular systems and you have described a very desirable module. I
                    > agree that you need as much control as possible and that would indeed make
                    > such a module expensive and large as I would prefer 16 grains but would
                    > settle on 8.
                    >
                    > If only :o)
                    >
                    > David
                    >
                    > David Salter
                    > Senior Consultant
                    > PSG
                    >
                    > Reuters Messaging: david.salter.reuters.com@...<david.salter.reuters.com%40reuters.net>
                    > (t) +44 (0)20 7542 2402 | (m) 07990562402 | (f) 52699
                    >
                    > Get the latest news at Reuters.com <http://reuters.com/> <
                    > http://www.reuters.com/>
                    >
                    > ________________________________
                    >
                    > From: Doepfer_a100@yahoogroups.com <Doepfer_a100%40yahoogroups.com>[mailto:
                    > Doepfer_a100@yahoogroups.com <Doepfer_a100%40yahoogroups.com>] On Behalf
                    > Of Denis Gökdag
                    > Sent: 05 March 2008 13:33
                    > To: Doepfer_a100@yahoogroups.com <Doepfer_a100%40yahoogroups.com>
                    > Subject: Re: [Doepfer_a100] Re: granular processor & generato
                    >
                    > Weeeelllll.....
                    >
                    > there is no reason a DSP-based granular module should not be able to
                    > output n grains to n outputs. Grains are computed as separate
                    > entities and get summed just before the output. So skipping the
                    > summing stage and replacing it with n outputs would not be such an
                    > issue. It would raise the price of a module because you'd use more D/
                    > A's, though. So filter, amp and panning could all be done outside
                    > such a module, provided the module outputs trigger data etc for each
                    > grain.
                    >
                    > What would really make the whole thing rely on a high-powered DSP (or
                    > more than one) is if you want to be able to modulate transposition/
                    > position etc at audio rate....IMHO a must in a modular (can you spell
                    > "control rate vs audio rate" in reaktor? ugh)
                    >
                    > I personally think that an 8 or 16 grain system would be sufficient,
                    > provided there was a way to link more than one in an "intelligent"
                    > manner.
                    >
                    > Now what i think is the main issue with a module like this is: what
                    > control philosophy does it use? You can either have dedicated control
                    > of every grain or use some sort of "structural logic" that the module
                    > itself applies (aka "grain density" instead of separate grain
                    > triggers, "pitch jitter" instead of CV control of every grain pitch,
                    > "density evolution" instead of variable rate grain trigger signal). I
                    > personally think that in a modular system you'd want the discrete
                    > version, if i want meta-control only i can use reaktor or anything
                    > else.....the cool thing is to have the grain stuff *integrate*
                    > perfectly into the system, and for that you definitely need access to
                    > the individual grain's parameters. Now the downside of this is that
                    > it would be a large and expensive module, and that doing some of the
                    > standard meta-attribute stuff would take a lot of patching. Maybe
                    > here there would be a good opportunity to create some structured data
                    > modules.....;-)
                    >
                    > Now imagine what you could do with a grain thang at audio rate....use
                    > an audio rate pulse for the triggering of a grain, clock a sequencer
                    > with the same pulse and have that select playback position and grain
                    > transposition (or grain duration) of the grain thang, effectively
                    > getting a waveform that is F*N in length ( F being pulse frequency
                    > expressed in seconds, N being number of steps in the sequence). And
                    > we're just talking about grain #1 here :-)
                    >
                    > my 2 ct
                    >
                    > d
                    >
                    > On 05. Mar 2008, at 9:12 AM, Korhan Erel wrote:
                    >
                    > > Hi Carlos,
                    > >
                    > > As I said in my earlier mail that even a 4-grain system would cost a
                    > > fortune. On the other hand, a module that includes a DSP programmed
                    > > to do
                    > > granular synthesis would also cost a lot, given that it will have
                    > > to be a
                    > > powerful DSP to handle a high number of grains. It would also have to
                    > > include features like slew, filter, pitch shifting, amp, panning,
                    > > etc, as
                    > > you would not be able to process grains separately with modules.
                    > >
                    > > Korhan
                    > >
                    > > On 3/5/08, Carlos <bushwick@... <bushwick%40gmail.com> <mailto:
                    > bushwick%40gmail.com> > wrote:
                    > > >
                    > > > Granular synthesis uses anywhere from a few dozen grains to
                    > > thousands of
                    > > > them.being able to change the number of grains is essential to
                    > > get a good
                    > > > variety of sounds, I don't think a few fixed grains would do the
                    > > trick
                    > > >
                    > > > --- In Doepfer_a100@yahoogroups.com <Doepfer_a100%40yahoogroups.com><mailto:
                    > Doepfer_a100%40yahoogroups.com> <Doepfer_a100%
                    > > 40yahoogroups.com>,
                    > > > "Korhan Erel" <listekutusu@...> wrote:
                    > > > >
                    > > > > Since the A-112s cannot toggle between record and play, my idea
                    > > of the
                    > > > > granular synthesis can work only on prerecorded samples
                    > > (assuming it was
                    > > > a
                    > > > > good/feasible idea to start with)
                    > > > >
                    > > > > On 3/3/08, Korhan Erel <listekutusu@...> wrote:
                    > > > > >
                    > > > > > Can several A-112s be used to construct a simple granular
                    > > synth, with
                    > > > the
                    > > > > > A-112s in wavetable mode? Each A-112 would represent a grain
                    > > going
                    > > > into a
                    > > > > > filter and then into a VCA, shaped by a ADSR? I guess a 4
                    > > grain synth
                    > > > would
                    > > > > > cost a small fortune, but it's probably worth it.
                    > > > > >
                    > > > > > On 2/17/08, gasp_uleg <uleg2@...> wrote:
                    > > > > > >
                    > > > > > > i am a fanatic of modular concept but i never had the money
                    > > to build
                    > > > > > > the gigantic modular of my dreams so i went into virtual and i
                    > > > > > > specialized myself into Reaktor, where i've found
                    > > everythink i ever
                    > > > > > > needed.
                    > > > > > >
                    > > > > > > but the thing is that i deeply hate to use computer in
                    > > concerts so
                    > > > > > > now i'm trying to rebuild my reaktor setups into a totally
                    > > physical
                    > > > > > > way. with A100 and the other modulars everything i need can
                    > > > perfectly
                    > > > > > > be done EXCEPT granulation which has become my favourite sound
                    > > > > > > generator and modifier latelly.
                    > > > > > >
                    > > > > > > i think not only granular cloud-delay processing is
                    > > interesting.
                    > > > also
                    > > > > > > a granular sample player would be an amazing module.
                    > > > > > >
                    > > > > > > i don't know much about DSP but if people like clavia have
                    > > been able
                    > > > > > > to fit all what is inside a micromodular or if pedal
                    > > manufacturers
                    > > > > > > are now using DSP for their new guitar pedals, it must be
                    > > possible
                    > > > to
                    > > > > > > find some cheap DSP technology to be fit into a vc modular
                    > > format.
                    > > > > > >
                    > > > > > > of course i understand development and technical expertise
                    > > is very
                    > > > > > > diferent for digital stuff than
                    > > > > > > for purelly analog electronics design but i'm sure ther are
                    > > many
                    > > > > > > young geniuses running out there with their nice diplomas
                    > > in "very
                    > > > > > > really complicated informatics" just willing to be emploid to
                    > > > program
                    > > > > > > the complicated DSP algorithms for our modulars.
                    > > > > > >
                    > > > > > >
                    > > > > > >
                    > > > > >
                    > > > > >
                    > > > >
                    > > > >
                    > > > > [Non-text portions of this message have been removed]
                    > > > >
                    > > >
                    > > >
                    > > >
                    > >
                    > > [Non-text portions of this message have been removed]
                    > >
                    > >
                    > >
                    >
                    > [Non-text portions of this message have been removed]
                    >
                    > This email was sent to you by Reuters, the global news and information
                    > company.
                    > To find out more about Reuters visit www.about.reuters.com
                    >
                    > Any views expressed in this message are those of the individual sender,
                    > except where the sender specifically states them to be the views of
                    > Reuters Limited.
                    >
                    > Reuters Limited is part of the Reuters Group of companies, of which
                    > Reuters Group PLC is the ultimate parent company.
                    > Reuters Group PLC - Registered office address: The Reuters Building, South
                    > Colonnade, Canary Wharf, London E14 5EP, United Kingdom
                    > Registered No: 3296375
                    > Registered in England and Wales
                    >
                    > [Non-text portions of this message have been removed]
                    >
                    >
                    >


                    [Non-text portions of this message have been removed]
                  • gasp_uleg
                    yes denis, that would be a very nice aproach to it. -every grain could be externally trigered by an lfo or oscilator. -in case of a grain processor a separate
                    Message 9 of 28 , Mar 5, 2008
                    • 0 Attachment
                      yes denis, that would be a very nice aproach to it.
                      -every grain could be externally trigered by an lfo or oscilator.
                      -in case of a grain processor a separate triger for recording and
                      another for playback so pitch could be controlled by two ways.
                      -a cv input to control the playback direction of the grain
                      -a link connector could be included to add more grains if more
                      complexity is be needed.

                      gasp_uleg


                      --- In Doepfer_a100@yahoogroups.com, Denis Gökdag <q-art@...> wrote:
                      >
                      > Weeeelllll.....
                      >
                      > there is no reason a DSP-based granular module should not be able
                      to
                      > output n grains to n outputs. Grains are computed as separate
                      > entities and get summed just before the output. So skipping the
                      > summing stage and replacing it with n outputs would not be such an
                      > issue. It would raise the price of a module because you'd use more
                      D/
                      > A's, though. So filter, amp and panning could all be done outside
                      > such a module, provided the module outputs trigger data etc for
                      each
                      > grain.
                      >
                      > What would really make the whole thing rely on a high-powered DSP
                      (or
                      > more than one) is if you want to be able to modulate transposition/
                      > position etc at audio rate....IMHO a must in a modular (can you
                      spell
                      > "control rate vs audio rate" in reaktor? ugh)
                      >
                      > I personally think that an 8 or 16 grain system would be
                      sufficient,
                      > provided there was a way to link more than one in an "intelligent"
                      > manner.
                      >
                      > Now what i think is the main issue with a module like this is:
                      what
                      > control philosophy does it use? You can either have dedicated
                      control
                      > of every grain or use some sort of "structural logic" that the
                      module
                      > itself applies (aka "grain density" instead of separate grain
                      > triggers, "pitch jitter" instead of CV control of every grain
                      pitch,
                      > "density evolution" instead of variable rate grain trigger signal).
                      I
                      > personally think that in a modular system you'd want the discrete
                      > version, if i want meta-control only i can use reaktor or anything
                      > else.....the cool thing is to have the grain stuff *integrate*
                      > perfectly into the system, and for that you definitely need access
                      to
                      > the individual grain's parameters. Now the downside of this is
                      that
                      > it would be a large and expensive module, and that doing some of
                      the
                      > standard meta-attribute stuff would take a lot of patching. Maybe
                      > here there would be a good opportunity to create some structured
                      data
                      > modules.....;-)
                      >
                      >
                      > Now imagine what you could do with a grain thang at audio
                      rate....use
                      > an audio rate pulse for the triggering of a grain, clock a
                      sequencer
                      > with the same pulse and have that select playback position and
                      grain
                      > transposition (or grain duration) of the grain thang, effectively
                      > getting a waveform that is F*N in length ( F being pulse frequency
                      > expressed in seconds, N being number of steps in the sequence).
                      And
                      > we're just talking about grain #1 here :-)
                      >
                      >
                      > my 2 ct
                      >
                      > d
                      >
                      >
                      >
                      > On 05. Mar 2008, at 9:12 AM, Korhan Erel wrote:
                      >
                      > > Hi Carlos,
                      > >
                      > > As I said in my earlier mail that even a 4-grain system would
                      cost a
                      > > fortune. On the other hand, a module that includes a DSP
                      programmed
                      > > to do
                      > > granular synthesis would also cost a lot, given that it will
                      have
                      > > to be a
                      > > powerful DSP to handle a high number of grains. It would also
                      have to
                      > > include features like slew, filter, pitch shifting, amp,
                      panning,
                      > > etc, as
                      > > you would not be able to process grains separately with modules.
                      > >
                      > > Korhan
                      > >
                      > > On 3/5/08, Carlos <bushwick@...> wrote:
                      > > >
                      > > > Granular synthesis uses anywhere from a few dozen grains to
                      > > thousands of
                      > > > them.being able to change the number of grains is essential to
                      > > get a good
                      > > > variety of sounds, I don't think a few fixed grains would do
                      the
                      > > trick
                      > > >
                      > > > --- In Doepfer_a100@yahoogroups.com <Doepfer_a100%
                      > > 40yahoogroups.com>,
                      > > > "Korhan Erel" <listekutusu@> wrote:
                      > > > >
                      > > > > Since the A-112s cannot toggle between record and play, my
                      idea
                      > > of the
                      > > > > granular synthesis can work only on prerecorded samples
                      > > (assuming it was
                      > > > a
                      > > > > good/feasible idea to start with)
                      > > > >
                      > > > > On 3/3/08, Korhan Erel <listekutusu@> wrote:
                      > > > > >
                      > > > > > Can several A-112s be used to construct a simple granular
                      > > synth, with
                      > > > the
                      > > > > > A-112s in wavetable mode? Each A-112 would represent a
                      grain
                      > > going
                      > > > into a
                      > > > > > filter and then into a VCA, shaped by a ADSR? I guess a 4
                      > > grain synth
                      > > > would
                      > > > > > cost a small fortune, but it's probably worth it.
                      > > > > >
                      > > > > > On 2/17/08, gasp_uleg <uleg2@> wrote:
                      > > > > > >
                      > > > > > > i am a fanatic of modular concept but i never had the
                      money
                      > > to build
                      > > > > > > the gigantic modular of my dreams so i went into virtual
                      and i
                      > > > > > > specialized myself into Reaktor, where i've found
                      > > everythink i ever
                      > > > > > > needed.
                      > > > > > >
                      > > > > > > but the thing is that i deeply hate to use computer in
                      > > concerts so
                      > > > > > > now i'm trying to rebuild my reaktor setups into a
                      totally
                      > > physical
                      > > > > > > way. with A100 and the other modulars everything i need
                      can
                      > > > perfectly
                      > > > > > > be done EXCEPT granulation which has become my favourite
                      sound
                      > > > > > > generator and modifier latelly.
                      > > > > > >
                      > > > > > > i think not only granular cloud-delay processing is
                      > > interesting.
                      > > > also
                      > > > > > > a granular sample player would be an amazing module.
                      > > > > > >
                      > > > > > > i don't know much about DSP but if people like clavia
                      have
                      > > been able
                      > > > > > > to fit all what is inside a micromodular or if pedal
                      > > manufacturers
                      > > > > > > are now using DSP for their new guitar pedals, it must
                      be
                      > > possible
                      > > > to
                      > > > > > > find some cheap DSP technology to be fit into a vc
                      modular
                      > > format.
                      > > > > > >
                      > > > > > > of course i understand development and technical
                      expertise
                      > > is very
                      > > > > > > diferent for digital stuff than
                      > > > > > > for purelly analog electronics design but i'm sure ther
                      are
                      > > many
                      > > > > > > young geniuses running out there with their nice
                      diplomas
                      > > in "very
                      > > > > > > really complicated informatics" just willing to be
                      emploid to
                      > > > program
                      > > > > > > the complicated DSP algorithms for our modulars.
                      > > > > > >
                      > > > > > >
                      > > > > > >
                      > > > > >
                      > > > > >
                      > > > >
                      > > > >
                      > > > > [Non-text portions of this message have been removed]
                      > > > >
                      > > >
                      > > >
                      > > >
                      > >
                      > > [Non-text portions of this message have been removed]
                      > >
                      > >
                      > >
                      >
                      >
                      >
                      > [Non-text portions of this message have been removed]
                      >
                    • Denis Gökdag
                      ... Yeah, that s basically what i meant. Let me focus on a grain playback module. It would get it s source files via USB, up to one file per voice, or possibly
                      Message 10 of 28 , Mar 6, 2008
                      • 0 Attachment
                        > yes that would be a very nice aproac to it.
                        > also:
                        > -every grain could even be externally trigered by an lfo or oscilator.
                        Yeah, that's basically what i meant. Let me focus on a grain playback
                        module. It would get it's source files via USB, up to one file per
                        voice, or possibly from the memory of a possible other grain module
                        ( like a realtime memory recorder....). One voice would have the
                        following inputs/functions:

                        - trigger input to start playback of a grain.

                        - 3-way trigger-mode switch
                        --------mode 1: starts a grain on every trigger; if a new trigger
                        arrives while a grain is still running, the voice crossfades to the
                        new grain
                        --------mode 2: starts a grain when a trigger is received UNLESS a
                        grain is already being played back. the trigger signal is forwarded
                        to a trigger output socket (which could be used to trigger a
                        different voice)
                        --------mode 3: sampler mode, where the input expects a GATE rather
                        than a trigger. rising gate will start a grain, which will continue
                        playing looped while gate is high

                        ---trigger thru socket which forwards either the trigger signal like
                        a multiple (mode 1), routes non-played triggers thru (mode 2) or
                        outputs a trigger whenever the loop "turns around" (mode 3)

                        --- "grain is playing" gate output: outputs a gate whenever a grain
                        is being played, gate becomes low when the grain fade-out starts (so
                        you wont get just a permanent high level in case of mode 1 and
                        overlapping grains); this makes triggering envelopes etc for
                        processing grains possible

                        - manual control and attenuated CV input for grain length: these
                        values will only be evaluated at grain start time

                        - mode switch for grain length
                        --------mode 1: absolute mode #1, where a CV of 5V results in a grain
                        length of 500ms
                        --------mode 2: absolute mode #2, where 5V = 2.5
                        --------mode 3: relative mode, where 5V equals the length of the
                        entire file in seconds

                        ----grain length CV output, that outputs the current grain length as CV

                        - manual control and attenuated CV input for grain transposition;
                        only evaluated at grain start

                        - attenuated CV input for grain pitch; evaluated in realtime at
                        sample rate (for "pitch jitter" effetcs or envelope control of pitch
                        variation during a grain etc)

                        ---- pitch CV output, which is the transposition (in S/H form as used
                        by the grain module) plus pitch CVs summed

                        - manual control and attenuated CV input for grain start location
                        within file; only evaluated at grain start

                        - grain start location mode switch:
                        -------mode 1: relative mode, where 5V = last sample word of file
                        (in which case a grain would start at the beginning of the file); the
                        manual start time control acts as an offset and has a range over the
                        entire file
                        -------mode 2: absolute mode, where 5V = 1 second; manual control is
                        offset as in mode 1
                        -------mode 3: stepped mode, where the CV input is quantised into 16
                        or 32 steps, which step through the file in 16 or 32 equal steps
                        (making beat-rearrangement possible etc); manual control is an offset
                        for fine-tuning the virtual "1" of the file.

                        ---grain start CV output, which outputs the starting position within
                        the file of the current grain, where the last sample word of the file
                        equals 5V, updated on grain start

                        --- current playback position CV output, which outputs the current
                        position within a grain (!!) as a CV, where start of grain equals 0V
                        and end of grain equals 5V....this is basically a rising ramp at the
                        length of the current grain, or a sawtooth oscillator in case of
                        looped playback. yummy!

                        - manual control for fade-in/out time of the grain from 0 to 50% of
                        grain length value OR absolute from 0 to 20 ms dpending on the state
                        of the

                        - fade mode switch as described above

                        --- fade envelope CV output, which outputs a rising ramp while grain
                        fades in, falling ramp while grain fades out and 5V while grain is
                        playing

                        - grain playback direction switch and gate input where 0V = forward
                        and 5V = reverse. when in looped mode 5V means alternating forward-
                        backward loop

                        - grain audio output



                        This would result in a total of 14 sockets, 9 pots and 4
                        switches......so a 4-voice module would basically be around the size
                        of an a-154 + a-155 combo.

                        Gotta forget about the 8-voice. Just get two or three of the 4-voice
                        ones.

                        Yeah.


                        Oh and whoever builds this, get me a free one ;-)



                        l8a,
                        d
                      • gasp_uleg
                        i think a grain generator should have a very diferent aproach than a grain processor. this is how i see a grain generator: grains are not fixed samples, they
                        Message 11 of 28 , Mar 6, 2008
                        • 0 Attachment
                          i think a grain generator should have a very diferent aproach than a grain
                          processor.

                          this is how i see a grain generator:


                          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...)


                          - a grain generator should be able to stock a series of more or less long
                          samples (stored into a usb memory or a SDcard or whatever)

                          - a cv select input would allow to choose the sample to be granulated

                          - a cv position pointer would allow to choose where from that sample the
                          grain is taken.

                          - a couple of cv start and end loop position pointers would allow the
                          whole sample to be put in loop (0v=start of the sample, 5v=end of the
                          sample)

                          - a cv lag processor for the position pointer would allow to smooth the
                          transition of granulation travelling thru the long sample

                          - a cv lenght would control how long is the grain lasting.

                          - a clock/trig input would control the density of grains

                          - a gate input would trigger the playback of the grains

                          - a cv input to control grains pitch

                          - a cv input to control main sample's pitch

                          - a cv input for atack time of the grains

                          - a cv input for the release time of the grains

                          - a cv feedback would allow to feed the grains back to themselves

                          - a cv delay time would allow to delay the signal for grain's feedback


                          more thoughts on this later


                          --- In Doepfer_a100@yahoogroups.com, Denis Gökdag <q-art@...> wrote:
                          >
                          >
                          > > yes that would be a very nice aproac to it.
                          > > also:
                          > > -every grain could even be externally trigered by an lfo or oscilator.
                          > Yeah, that's basically what i meant. Let me focus on a grain playback
                          > module. It would get it's source files via USB, up to one file per
                          > voice, or possibly from the memory of a possible other grain module
                          > ( like a realtime memory recorder....). One voice would have the
                          > following inputs/functions:
                          >
                          > - trigger input to start playback of a grain.
                          >
                          > - 3-way trigger-mode switch
                          > --------mode 1: starts a grain on every trigger; if a new trigger
                          > arrives while a grain is still running, the voice crossfades to the
                          > new grain
                          > --------mode 2: starts a grain when a trigger is received UNLESS a
                          > grain is already being played back. the trigger signal is forwarded
                          > to a trigger output socket (which could be used to trigger a
                          > different voice)
                          > --------mode 3: sampler mode, where the input expects a GATE rather
                          > than a trigger. rising gate will start a grain, which will continue
                          > playing looped while gate is high
                          >
                          > ---trigger thru socket which forwards either the trigger signal like
                          > a multiple (mode 1), routes non-played triggers thru (mode 2) or
                          > outputs a trigger whenever the loop "turns around" (mode 3)
                          >
                          > --- "grain is playing" gate output: outputs a gate whenever a grain
                          > is being played, gate becomes low when the grain fade-out starts (so
                          > you wont get just a permanent high level in case of mode 1 and
                          > overlapping grains); this makes triggering envelopes etc for
                          > processing grains possible
                          >
                          > - manual control and attenuated CV input for grain length: these
                          > values will only be evaluated at grain start time
                          >
                          > - mode switch for grain length
                          > --------mode 1: absolute mode #1, where a CV of 5V results in a grain
                          > length of 500ms
                          > --------mode 2: absolute mode #2, where 5V = 2.5
                          > --------mode 3: relative mode, where 5V equals the length of the
                          > entire file in seconds
                          >
                          > ----grain length CV output, that outputs the current grain length as CV
                          >
                          > - manual control and attenuated CV input for grain transposition;
                          > only evaluated at grain start
                          >
                          > - attenuated CV input for grain pitch; evaluated in realtime at
                          > sample rate (for "pitch jitter" effetcs or envelope control of pitch
                          > variation during a grain etc)
                          >
                          > ---- pitch CV output, which is the transposition (in S/H form as used
                          > by the grain module) plus pitch CVs summed
                          >
                          > - manual control and attenuated CV input for grain start location
                          > within file; only evaluated at grain start
                          >
                          > - grain start location mode switch:
                          > -------mode 1: relative mode, where 5V = last sample word of file
                          > (in which case a grain would start at the beginning of the file); the
                          > manual start time control acts as an offset and has a range over the
                          > entire file
                          > -------mode 2: absolute mode, where 5V = 1 second; manual control is
                          > offset as in mode 1
                          > -------mode 3: stepped mode, where the CV input is quantised into 16
                          > or 32 steps, which step through the file in 16 or 32 equal steps
                          > (making beat-rearrangement possible etc); manual control is an offset
                          > for fine-tuning the virtual "1" of the file.
                          >
                          > ---grain start CV output, which outputs the starting position within
                          > the file of the current grain, where the last sample word of the file
                          > equals 5V, updated on grain start
                          >
                          > --- current playback position CV output, which outputs the current
                          > position within a grain (!!) as a CV, where start of grain equals 0V
                          > and end of grain equals 5V....this is basically a rising ramp at the
                          > length of the current grain, or a sawtooth oscillator in case of
                          > looped playback. yummy!
                          >
                          > - manual control for fade-in/out time of the grain from 0 to 50% of
                          > grain length value OR absolute from 0 to 20 ms dpending on the state
                          > of the
                          >
                          > - fade mode switch as described above
                          >
                          > --- fade envelope CV output, which outputs a rising ramp while grain
                          > fades in, falling ramp while grain fades out and 5V while grain is
                          > playing
                          >
                          > - grain playback direction switch and gate input where 0V = forward
                          > and 5V = reverse. when in looped mode 5V means alternating forward-
                          > backward loop
                          >
                          > - grain audio output
                          >
                          >
                          >
                          > This would result in a total of 14 sockets, 9 pots and 4
                          > switches......so a 4-voice module would basically be around the size
                          > of an a-154 + a-155 combo.
                          >
                          > Gotta forget about the 8-voice. Just get two or three of the 4-voice
                          > ones.
                          >
                          > Yeah.
                          >
                          >
                          > Oh and whoever builds this, get me a free one ;-)
                          >
                          >
                          >
                          > l8a,
                          > d
                          >
                        • Denis Gökdag
                          ... 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
                          Message 12 of 28 , Mar 7, 2008
                          • 0 Attachment
                            >
                            > 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
                            >
                            > - a cv input for the release time of the grains
                            >
                            > - a cv feedback would allow to feed the grains back to themselves
                            What do you want this to do? Overwrite the source file with the
                            output signal? Or just repeat a grain? The latter is what the looped-
                            mode in my suggestion would do, the other would basically pose the
                            question to which location in the source you want to write....or
                            wether you want a grain *processor* (which would be about writing to
                            and reading from the same memory).

                            >
                            > - a cv delay time would allow to delay the signal for grain's feedback
                            Again, this mixes up a processor and a generator.....there is no need
                            for a delay parameter as you have full control of when a grain is
                            started and from which part of the file it is being "grabbed"....and
                            writing to the memory that is being read from is more of a grain
                            *processor" application. Echoes on the grains could be done with an
                            external delay module with greater flexibility.


                            ahw, got awfully dsp-nerdy again ;-)

                            l8a,
                            d
                          • David Salter
                            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
                            Message 13 of 28 , Mar 7, 2008
                            • 0 Attachment
                              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@...
                              (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
                              >
                              > - a cv input for the release time of the grains
                              >
                              > - a cv feedback would allow to feed the grains back to themselves
                              What do you want this to do? Overwrite the source file with the
                              output signal? Or just repeat a grain? The latter is what the looped-
                              mode in my suggestion would do, the other would basically pose the
                              question to which location in the source you want to write....or
                              wether you want a grain *processor* (which would be about writing to
                              and reading from the same memory).

                              >
                              > - a cv delay time would allow to delay the signal for grain's feedback
                              Again, this mixes up a processor and a generator.....there is no need
                              for a delay parameter as you have full control of when a grain is
                              started and from which part of the file it is being "grabbed"....and
                              writing to the memory that is being read from is more of a grain
                              *processor" application. Echoes on the grains could be done with an
                              external delay module with greater flexibility.

                              ahw, got awfully dsp-nerdy again ;-)

                              l8a,
                              d






                              This email was sent to you by Reuters, the global news and information company.
                              To find out more about Reuters visit www.about.reuters.com

                              Any views expressed in this message are those of the individual sender,
                              except where the sender specifically states them to be the views of Reuters Limited.

                              Reuters Limited is part of the Reuters Group of companies, of which Reuters Group PLC is the ultimate parent company.
                              Reuters Group PLC - Registered office address: The Reuters Building, South Colonnade, Canary Wharf, London E14 5EP, United Kingdom
                              Registered No: 3296375
                              Registered in England and Wales



                              [Non-text portions of this message have been removed]
                            • Bakis Sirros
                              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
                              Message 14 of 28 , Mar 7, 2008
                              • 0 Attachment
                                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@...> 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@...
                                > (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
                              • Richard Scott
                                seriously, the fact that ideas and designs get hammered out on this list and that doepfer actually listen to users needs and builds a fair prortion of what we
                                Message 15 of 28 , Mar 7, 2008
                                • 0 Attachment
                                  seriously, the fact that ideas and designs get hammered out on this list and that doepfer actually listen to users needs and builds a fair prortion of what we discuss is great. Part of loving modulars is the playing and the sound, but part is the planning, thinking, design... its great that we can be involved in this aspect too

                                  BTW I have no real idea what they are talking about either!

                                  Richard

                                  ----- Original Message -----
                                  From: David Salter
                                  To: Doepfer_a100@yahoogroups.com
                                  Sent: Friday, March 07, 2008 3:32 PM
                                  Subject: RE: [Doepfer_a100] Re: granular processor & generato


                                  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@...
                                  (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
                                  >
                                  > - a cv input for the release time of the grains
                                  >
                                  > - a cv feedback would allow to feed the grains back to themselves
                                  What do you want this to do? Overwrite the source file with the
                                  output signal? Or just repeat a grain? The latter is what the looped-
                                  mode in my suggestion would do, the other would basically pose the
                                  question to which location in the source you want to write....or
                                  wether you want a grain *processor* (which would be about writing to
                                  and reading from the same memory).

                                  >
                                  > - a cv delay time would allow to delay the signal for grain's feedback
                                  Again, this mixes up a processor and a generator.....there is no need
                                  for a delay parameter as you have full control of when a grain is
                                  started and from which part of the file it is being "grabbed"....and
                                  writing to the memory that is being read from is more of a grain
                                  *processor" application. Echoes on the grains could be done with an
                                  external delay module with greater flexibility.

                                  ahw, got awfully dsp-nerdy again ;-)

                                  l8a,
                                  d

                                  This email was sent to you by Reuters, the global news and information company.
                                  To find out more about Reuters visit www.about.reuters.com

                                  Any views expressed in this message are those of the individual sender,
                                  except where the sender specifically states them to be the views of Reuters Limited.

                                  Reuters Limited is part of the Reuters Group of companies, of which Reuters Group PLC is the ultimate parent company.
                                  Reuters Group PLC - Registered office address: The Reuters Building, South Colonnade, Canary Wharf, London E14 5EP, United Kingdom
                                  Registered No: 3296375
                                  Registered in England and Wales

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





                                  --
                                  I am using the free version of SPAMfighter for private users.
                                  It has removed 378 spam emails to date.
                                  Paying users do not have this message in their emails.
                                  Get the free SPAMfighter here: http://www.spamfighter.com/len


                                  [Non-text portions of this message have been removed]
                                • David Salter
                                  I understand the process (if not all the technical stuff) as I use Metasynth on my Mac and the end results are amazing. To be able to apply a similar - though
                                  Message 16 of 28 , Mar 7, 2008
                                  • 0 Attachment
                                    I understand the process (if not all the technical stuff) as I use Metasynth on my Mac and the end results are amazing.

                                    To be able to apply a similar - though in reality probably a cut down - process in real time with in a modular system would be wonderful.

                                    david



                                    David Salter
                                    Senior Consultant
                                    PSG

                                    Reuters Messaging: david.salter.reuters.com@...
                                    (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 Richard Scott
                                    Sent: 07 March 2008 15:39
                                    To: Doepfer_a100@yahoogroups.com
                                    Subject: Re: [Doepfer_a100] Re: granular processor & generato



                                    seriously, the fact that ideas and designs get hammered out on this list and that doepfer actually listen to users needs and builds a fair prortion of what we discuss is great. Part of loving modulars is the playing and the sound, but part is the planning, thinking, design... its great that we can be involved in this aspect too

                                    BTW I have no real idea what they are talking about either!

                                    Richard

                                    ----- Original Message -----
                                    From: David Salter
                                    To: Doepfer_a100@yahoogroups.com <mailto:Doepfer_a100%40yahoogroups.com>
                                    Sent: Friday, March 07, 2008 3:32 PM
                                    Subject: RE: [Doepfer_a100] Re: granular processor & generato

                                    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@... <mailto:david.salter.reuters.com%40reuters.net>
                                    (t) +44 (0)20 7542 2402 | (m) 07990562402 | (f) 52699

                                    Get the latest news at Reuters.com <http://www.reuters.com/ <http://www.reuters.com/> >

                                    ________________________________

                                    From: Doepfer_a100@yahoogroups.com <mailto:Doepfer_a100%40yahoogroups.com> [mailto:Doepfer_a100@yahoogroups.com <mailto:Doepfer_a100%40yahoogroups.com> ] On Behalf Of Denis Gökdag
                                    Sent: 07 March 2008 14:11
                                    To: Doepfer_a100@yahoogroups.com <mailto:Doepfer_a100%40yahoogroups.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
                                    >
                                    > - a cv input for the release time of the grains
                                    >
                                    > - a cv feedback would allow to feed the grains back to themselves
                                    What do you want this to do? Overwrite the source file with the
                                    output signal? Or just repeat a grain? The latter is what the looped-
                                    mode in my suggestion would do, the other would basically pose the
                                    question to which location in the source you want to write....or
                                    wether you want a grain *processor* (which would be about writing to
                                    and reading from the same memory).

                                    >
                                    > - a cv delay time would allow to delay the signal for grain's feedback
                                    Again, this mixes up a processor and a generator.....there is no need
                                    for a delay parameter as you have full control of when a grain is
                                    started and from which part of the file it is being "grabbed"....and
                                    writing to the memory that is being read from is more of a grain
                                    *processor" application. Echoes on the grains could be done with an
                                    external delay module with greater flexibility.

                                    ahw, got awfully dsp-nerdy again ;-)

                                    l8a,
                                    d

                                    This email was sent to you by Reuters, the global news and information company.
                                    To find out more about Reuters visit www.about.reuters.com

                                    Any views expressed in this message are those of the individual sender,
                                    except where the sender specifically states them to be the views of Reuters Limited.

                                    Reuters Limited is part of the Reuters Group of companies, of which Reuters Group PLC is the ultimate parent company.
                                    Reuters Group PLC - Registered office address: The Reuters Building, South Colonnade, Canary Wharf, London E14 5EP, United Kingdom
                                    Registered No: 3296375
                                    Registered in England and Wales

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

                                    --
                                    I am using the free version of SPAMfighter for private users.
                                    It has removed 378 spam emails to date.
                                    Paying users do not have this message in their emails.
                                    Get the free SPAMfighter here: http://www.spamfighter.com/len <http://www.spamfighter.com/len>

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






                                    This email was sent to you by Reuters, the global news and information company.
                                    To find out more about Reuters visit www.about.reuters.com

                                    Any views expressed in this message are those of the individual sender,
                                    except where the sender specifically states them to be the views of Reuters Limited.

                                    Reuters Limited is part of the Reuters Group of companies, of which Reuters Group PLC is the ultimate parent company.
                                    Reuters Group PLC - Registered office address: The Reuters Building, South Colonnade, Canary Wharf, London E14 5EP, United Kingdom
                                    Registered No: 3296375
                                    Registered in England and Wales



                                    [Non-text portions of this message have been removed]
                                  • Denis Gökdag
                                    ... Not cut-down at all! Imagine taking the CV s for grain parameters from a vocoder analysis section, and using sequencers and VCOs for triggering/parameter
                                    Message 17 of 28 , Mar 7, 2008
                                    • 0 Attachment
                                      >
                                      > To be able to apply a similar - though in reality probably a cut
                                      > down - process in real time with in a modular system would be
                                      > wonderful.
                                      >

                                      Not cut-down at all! Imagine taking the CV's for grain parameters
                                      from a vocoder analysis section, and using sequencers and VCOs for
                                      triggering/parameter automation....grains "synced" to an
                                      oscillator....etc etc....*grin*

                                      Compared to Metasynth you'd get less grains simultaneously, and no 2D/
                                      3D control.....but a ton more options.


                                      d
                                    • David Salter
                                      I would be interested if anyone on this board had the capability to design and cost out this module. It would be interesting to know if it s commercially
                                      Message 18 of 28 , Mar 7, 2008
                                      • 0 Attachment
                                        I would be interested if anyone on this board had the capability to design and cost out this module.

                                        It would be interesting to know if it's commercially viable to build.

                                        David

                                        David Salter
                                        Senior Consultant
                                        PSG

                                        Reuters Messaging: david.salter.reuters.com@...
                                        (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 16:21
                                        To: Doepfer_a100@yahoogroups.com
                                        Subject: Re: [Doepfer_a100] Re: granular processor & generato



                                        >
                                        > To be able to apply a similar - though in reality probably a cut
                                        > down - process in real time with in a modular system would be
                                        > wonderful.
                                        >

                                        Not cut-down at all! Imagine taking the CV's for grain parameters
                                        from a vocoder analysis section, and using sequencers and VCOs for
                                        triggering/parameter automation....grains "synced" to an
                                        oscillator....etc etc....*grin*

                                        Compared to Metasynth you'd get less grains simultaneously, and no 2D/
                                        3D control.....but a ton more options.

                                        d





                                        This email was sent to you by Reuters, the global news and information company.
                                        To find out more about Reuters visit www.about.reuters.com

                                        Any views expressed in this message are those of the individual sender,
                                        except where the sender specifically states them to be the views of Reuters Limited.

                                        Reuters Limited is part of the Reuters Group of companies, of which Reuters Group PLC is the ultimate parent company.
                                        Reuters Group PLC - Registered office address: The Reuters Building, South Colonnade, Canary Wharf, London E14 5EP, United Kingdom
                                        Registered No: 3296375
                                        Registered in England and Wales



                                        [Non-text portions of this message have been removed]
                                      • gasp_uleg
                                        i totally agree with you, denis, that to leave as much external control as possible would not only lower the strain on the dsp but would also allow to
                                        Message 19 of 28 , Mar 7, 2008
                                        • 0 Attachment
                                          i totally agree with you, denis, that to leave as much external
                                          control as possible would not only lower the strain on the dsp but
                                          would also allow to experiment a lot with these controls.

                                          but at the same time that implies the absolute need more modules to
                                          control even its most basic parameters.

                                          that's maybe more simplicity versus verstility question...

                                          i'm not sure about what i would prefer: to be able to do incredible
                                          things with a complex system involving many modules to do granulation
                                          or to have more "concentrated" kind of granular module needing much
                                          less external stuff so i can get more granulators in a smaller rack
                                          space for concerts.

                                          i'm very atracted on both ways...


                                          for the details of our discussion please see my next message




                                          --- In Doepfer_a100@yahoogroups.com, Denis Gökdag <q-art@...> wrote:
                                          >
                                          > >
                                          > > 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
                                          > >
                                          > > - a cv input for the release time of the grains
                                          > >
                                          > > - a cv feedback would allow to feed the grains back to themselves
                                          > What do you want this to do? Overwrite the source file with the
                                          > output signal? Or just repeat a grain? The latter is what the
                                          looped-
                                          > mode in my suggestion would do, the other would basically pose the
                                          > question to which location in the source you want to write....or
                                          > wether you want a grain *processor* (which would be about writing
                                          to
                                          > and reading from the same memory).
                                          >
                                          > >
                                          > > - a cv delay time would allow to delay the signal for grain's
                                          feedback
                                          > Again, this mixes up a processor and a generator.....there is no
                                          need
                                          > for a delay parameter as you have full control of when a grain is
                                          > started and from which part of the file it is being
                                          "grabbed"....and
                                          > writing to the memory that is being read from is more of a grain
                                          > *processor" application. Echoes on the grains could be done with
                                          an
                                          > external delay module with greater flexibility.
                                          >
                                          >
                                          > ahw, got awfully dsp-nerdy again ;-)
                                          >
                                          > l8a,
                                          > d
                                          >
                                        • gasp_uleg
                                          -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.
                                          Message 20 of 28 , Mar 7, 2008
                                          • 0 Attachment
                                            -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.

                                            when using a lower frecuency clock (lfo range) then gaps between the
                                            grains could appear if the frecuency of the clock is lower
                                            than the lenght of the grain.

                                            -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.


                                            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.

                                            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.

                                            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.

                                            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)

                                            more later...













                                            --- In Doepfer_a100@yahoogroups.com, Denis Gökdag <q-art@...> wrote:
                                            >
                                            > >
                                            > > 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
                                            > >
                                            > > - a cv input for the release time of the grains
                                            > >
                                            > > - a cv feedback would allow to feed the grains back to themselves
                                            > What do you want this to do? Overwrite the source file with the
                                            > output signal? Or just repeat a grain? The latter is what the
                                            looped-
                                            > mode in my suggestion would do, the other would basically pose the
                                            > question to which location in the source you want to write....or
                                            > wether you want a grain *processor* (which would be about writing
                                            to
                                            > and reading from the same memory).
                                            >
                                            > >
                                            > > - a cv delay time would allow to delay the signal for grain's
                                            feedback
                                            > Again, this mixes up a processor and a generator.....there is no
                                            need
                                            > for a delay parameter as you have full control of when a grain is
                                            > started and from which part of the file it is being
                                            "grabbed"....and
                                            > writing to the memory that is being read from is more of a grain
                                            > *processor" application. Echoes on the grains could be done with
                                            an
                                            > external delay module with greater flexibility.
                                            >
                                            >
                                            > ahw, got awfully dsp-nerdy again ;-)
                                            >
                                            > l8a,
                                            > d
                                            >
                                          • Denis Gökdag
                                            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.
                                            Message 21 of 28 , Mar 9, 2008
                                            • 0 Attachment
                                              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
                                            • gasp_uleg
                                              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
                                              Message 22 of 28 , Mar 11, 2008
                                              • 0 Attachment
                                                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, 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
                                                >
                                              • David Salter
                                                Gaspar, Historically I think you ll find that manufacturers were content to replicate, improve and innovate in the analogue domain. Only very recently have we
                                                Message 23 of 28 , Mar 11, 2008
                                                • 0 Attachment
                                                  Gaspar,

                                                  Historically I think you'll find that manufacturers were content to replicate, improve and innovate in the analogue domain.

                                                  Only very recently have we seen digital electronics being used in modular systems.

                                                  However there is a commercial aspect that because of the need of decent DSP (which is expensive) to make real time processing viable and the number of potential buyers it may not be worth the development cost.

                                                  I for one would love a granular module but not if it cost 1000 Euros or even 500 Euros.

                                                  What is a realistic price point for buyers?

                                                  David
                                                  David Salter
                                                  Senior Consultant
                                                  PSG

                                                  Reuters Messaging: david.salter.reuters.com@...
                                                  (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 gasp_uleg
                                                  Sent: 11 March 2008 15:55
                                                  To: Doepfer_a100@yahoogroups.com
                                                  Subject: [Doepfer_a100] Re: granular processor & generato



                                                  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 <mailto: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
                                                  >






                                                  This email was sent to you by Reuters, the global news and information company.
                                                  To find out more about Reuters visit www.about.reuters.com

                                                  Any views expressed in this message are those of the individual sender,
                                                  except where the sender specifically states them to be the views of Reuters Limited.

                                                  Reuters Limited is part of the Reuters Group of companies, of which Reuters Group PLC is the ultimate parent company.
                                                  Reuters Group PLC - Registered office address: The Reuters Building, South Colonnade, Canary Wharf, London E14 5EP, United Kingdom
                                                  Registered No: 3296375
                                                  Registered in England and Wales



                                                  [Non-text portions of this message have been removed]
                                                • Denis Gökdag
                                                  ... hmmm, no, no joke.... the best of both worlds is what i d call it ;-) i got a lot of great results from running reaktor through my modular and the other
                                                  Message 24 of 28 , Mar 11, 2008
                                                  • 0 Attachment
                                                    > 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?
                                                    >
                                                    hmmm, no, no joke...."the best of both worlds" is what i'd call it ;-)

                                                    i got a lot of great results from running reaktor through my modular
                                                    and the other way around. also cool is metasynth through a modular.....

                                                    only thing that lacks is an easy way to get DC CV's into the computer
                                                    for controlling parameters.


                                                    anyway, i'll go meet dieter tomorrow at the messe and i'll try to
                                                    convince him to build us something grainy ;-)


                                                    ###d
                                                  • Korhan Erel
                                                    Korg s Kaosspad III uses granular processing as far as I know, but haven t tried one yet. ... [Non-text portions of this message have been removed]
                                                    Message 25 of 28 , Mar 11, 2008
                                                    • 0 Attachment
                                                      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]
                                                    • gasp_uleg
                                                      well, here we are 8 years later of this nice conversation we had on granular synthesis in modular format... i am very excited about the news from Mutable
                                                      Message 26 of 28 , Jan 12
                                                      • 0 Attachment
                                                        well, here we are 8 years later of this nice conversation we had on granular synthesis in modular format...

                                                        i am very excited about the news from Mutable Instruments for their new CLOUDS module...
                                                        at last a serious candidate for modular granulation !

                                                        i have seen the other diferent proposals for it like the Qu-Bit Naebula which stupidly lacks of the absolutelly esential audio input option

                                                        or the very deceptioning, ridiculously expensive, counter-intuitive, un-necesarelly noisy and user un-friendly attempt from australian Mungo G0 with it's awfully made front panel (for the price they charge they could at least give a decent front panel instead of this horribly low-quality scratched aluminium plate...)

                                                        Mutable Instruments CLOUDS not only sounds great but it has an incredibly well designed and intuitive layout, with just the right amount of CV controlable parameters to be a great exploratory tool... and the design is simply gorgous !

                                                        and not only grains are here but also modal synthesis with ELEMENTS, another hyper intuitive and powerfull aproach of creative physical modeling with its exciter section and resonating filter array...

                                                        simple happyness !!!


                                                        the wait was long but it's finally here !
                                                        thank you Olivier !

                                                        Gaspar


                                                        Mutable Instruments - Clouds

                                                         


                                                        Mutable Instrument - Elements

                                                         

                                                      Your message has been successfully submitted and would be delivered to recipients shortly.