sflooper is not deprecated as far as I am aware. Where did you
see this? The opcode is newer than the fluid ones (only written
last september).

You can use cpsmidib with sflooper, nothing stops you from
that. Just plug its output into sflooper kpitch like
this

kpitch cpsmidib 2
ipitch cpsmidi
inote notnum

ar1, ar2 sflooper ivel, inote, kamp, kpitch/ipitch, ipreindex, kloopstart, 
kloopend, kcrossfade, ifn

kpitch/ipitch should give you a transposition ratio, which will shift
your pitch up or down depending on the value of your pitch bend.

Victor

----- Original Message ----- 
From: 
To: 
Sent: Friday, January 18, 2008 6:47 PM
Subject: [Csnd] Re: Re: Re: 'boulder' synthesis



hi,

indeed flooper2 or sflooper (better, because you have multisamples
already in a soundfont)  already does, according to the docs, allow
k-rate shifting of loop start, end, and crossfade shape and length.
so, a new opcode is unecessary for 'boulder synthesis' as described
below, since i could use k-rate noise to modulate these...

however, rather disappointingly, the sflooper has been considered
depricated in favor of the newer, yet seemingly less flexible or
readily usable 'fluid opcodes'. plus, for a microtonal tending
composer like myself, the sflooper opcode doesn't seem to allow the
use of 'cpsmidib' or the like, nor does it look like it inherited the
'iflag' method from sfplay which would allow this to be easily done,
alas.

how easy would it be to do another version of sflooper (maybe call it
sflooper2 or something) that would inherit the 'iflag' method which
allows the interpretation of xfreq as a cps value?

best,
AKJ

Quoting victor :

> or better flooper2...
> ----- Original Message ----- From: "Oeyvind Brandtsegg" 
> 
> To: 
> Sent: Friday, January 11, 2008 8:44 PM
> Subject: [Csnd] Re: 'boulder' synthesis
>
>
>> Maybe flooper would be a good opcode "base" for this kind of thing ?
>> Oeyvind
>>
>> 2008/1/11, aaron@akjmusic.com :
>>> Hi all,
>>>
>>> My friend and composer Christopher Bailey has used a technique he and a
>>> friend call 'boulder' synthesis: instead of looping a sampleduring a
>>> sustain portion of an envelope, where one can here the artificiality of
>>> looping points, etc. implement an 'engine' which does everything else a
>>> sample engine does, except that instead of looping to sustain a note, 
>>> one
>>> uses randomized, cross-faded segments of the original sample. This adds 
>>> a
>>> more life-like organic realism to a sustained tone when using samples. 
>>> The
>>> 'boulder' idea is that this is sort of a larger scale analog to granular
>>> synthesis. i have been most impressed with the results he has 
>>> illustrated
>>> to me. (In fact, I'm amazed that this idea isn't already more 
>>> widespread,
>>> even in commercial hardware)
>>>
>>> My question--I have an broadly-outlined idea of how to implement this in
>>> CSound (Chris does it in CMIX) with the diskin opcode, some F-tables to
>>> match MIDI notes with samples, etc., but might it not be more beneficial
>>> in the long run to implement this as an opcode, especially if it could 
>>> be
>>> built on modifying some existing codebase? Perhaps one could import
>>> soundfonts, and do everything that the fluidsynth code does, except 
>>> change
>>> the looping procedure for sustain parts of the envelope to the above
>>> described procedure instead.
>>>
>>> How easy would this be? I can imagine it would really be a neat addition
>>> to the CSound arsenal, especially for sample-loving folk. The opcode 
>>> might
>>> be called 'fluidboulder', and maybe for non-soundfont based sample work,
>>> instead of 'loscil' we could have 'boulderoscil' :)
>>>
>>> Best,
>>> AKJ.
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body 
>>> "unsubscribe csound"
>>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body 
>> "unsubscribe csound"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body
> "unsubscribe csound"





Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
csound"= 

Note that the fluid family of opcodes do sound great but they are CPU  
hogs when compared to the
soundfont family.

For realtime, I generally use the soundfont family.

-dB


On Jan 18, 2008, at 3:32 PM, aaron@akjmusic.com wrote:

> Quoting victor :
>
>> sflooper is not deprecated as far as I am aware. Where did you
>> see this? The opcode is newer than the fluid ones (only written
>> last september).
>
> I'm looking at http://www.csounds.com/manual/html/ 
> SiggenSample.html#SiggenSampleSF
>
> notice it says 'Old soundfont opcodes' and 'These opcodes can also  
> use soundfonts to generate sound. The usage of the fluid Opcodes  
> (above) is highly recommended instead of these opcodes.'
>
> am I looking at a bad manual or something?
>
>> You can use cpsmidib with sflooper, nothing stops you from
>> that. Just plug its output into sflooper kpitch like
>> this
>>
>> kpitch cpsmidib 2
>> ipitch cpsmidi
>> inote notnum
>>
>> ar1, ar2 sflooper ivel, inote, kamp, kpitch/ipitch, ipreindex,
>> kloopstart, kloopend, kcrossfade, ifn
>>
>> kpitch/ipitch should give you a transposition ratio, which will shift
>> your pitch up or down depending on the value of your pitch bend.
>
> you are right, this will work, however, it seems to be a slightly  
> kludgy workaround solution, involves a tiny overhead by having to  
> use division, and it seems strange and  inconsistent not to  
> consider at least giving the user the option of not having to do  
> the above solution when for instance 'sfplay', with the 'iflag'  
> option, doesn't force one to have to do so!
>
> best,
> AKJ.
>
>
>>
>> ----- Original Message ----- From: 
>> To: 
>> Sent: Friday, January 18, 2008 6:47 PM
>> Subject: [Csnd] Re: Re: Re: 'boulder' synthesis
>>
>>
>>
>> hi,
>>
>> indeed flooper2 or sflooper (better, because you have multisamples
>> already in a soundfont)  already does, according to the docs, allow
>> k-rate shifting of loop start, end, and crossfade shape and length.
>> so, a new opcode is unecessary for 'boulder synthesis' as described
>> below, since i could use k-rate noise to modulate these...
>>
>> however, rather disappointingly, the sflooper has been considered
>> depricated in favor of the newer, yet seemingly less flexible or
>> readily usable 'fluid opcodes'. plus, for a microtonal tending
>> composer like myself, the sflooper opcode doesn't seem to allow the
>> use of 'cpsmidib' or the like, nor does it look like it inherited the
>> 'iflag' method from sfplay which would allow this to be easily done,
>> alas.
>>
>> how easy would it be to do another version of sflooper (maybe call it
>> sflooper2 or something) that would inherit the 'iflag' method which
>> allows the interpretation of xfreq as a cps value?
>>
>> best,
>> AKJ
>>
>> Quoting victor :
>>
>>> or better flooper2...
>>> ----- Original Message ----- From: "Oeyvind Brandtsegg"  
>>> 
>>> To: 
>>> Sent: Friday, January 11, 2008 8:44 PM
>>> Subject: [Csnd] Re: 'boulder' synthesis
>>>
>>>
>>>> Maybe flooper would be a good opcode "base" for this kind of  
>>>> thing ?
>>>> Oeyvind
>>>>
>>>> 2008/1/11, aaron@akjmusic.com :
>>>>> Hi all,
>>>>>
>>>>> My friend and composer Christopher Bailey has used a technique  
>>>>> he and a
>>>>> friend call 'boulder' synthesis: instead of looping a  
>>>>> sampleduring a
>>>>> sustain portion of an envelope, where one can here the  
>>>>> artificiality of
>>>>> looping points, etc. implement an 'engine' which does  
>>>>> everything else a
>>>>> sample engine does, except that instead of looping to sustain a  
>>>>> note, one
>>>>> uses randomized, cross-faded segments of the original sample.  
>>>>> This adds a
>>>>> more life-like organic realism to a sustained tone when using  
>>>>> samples. The
>>>>> 'boulder' idea is that this is sort of a larger scale analog to  
>>>>> granular
>>>>> synthesis. i have been most impressed with the results he has  
>>>>> illustrated
>>>>> to me. (In fact, I'm amazed that this idea isn't already more  
>>>>> widespread,
>>>>> even in commercial hardware)
>>>>>
>>>>> My question--I have an broadly-outlined idea of how to  
>>>>> implement this in
>>>>> CSound (Chris does it in CMIX) with the diskin opcode, some F- 
>>>>> tables to
>>>>> match MIDI notes with samples, etc., but might it not be more  
>>>>> beneficial
>>>>> in the long run to implement this as an opcode, especially if  
>>>>> it could be
>>>>> built on modifying some existing codebase? Perhaps one could  
>>>>> import
>>>>> soundfonts, and do everything that the fluidsynth code does,  
>>>>> except change
>>>>> the looping procedure for sustain parts of the envelope to the  
>>>>> above
>>>>> described procedure instead.
>>>>>
>>>>> How easy would this be? I can imagine it would really be a neat  
>>>>> addition
>>>>> to the CSound arsenal, especially for sample-loving folk. The  
>>>>> opcode might
>>>>> be called 'fluidboulder', and maybe for non-soundfont based  
>>>>> sample work,
>>>>> instead of 'loscil' we could have 'boulderoscil' :)
>>>>>
>>>>> Best,
>>>>> AKJ.
>>>>>
>>>>>
>>>>>
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body   
>>>>> "unsubscribe csound"
>>>>>
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body   
>>>> "unsubscribe csound"
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>> "unsubscribe csound"
>>
>>
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> "unsubscribe csound"= Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> "unsubscribe csound"
>
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"