The fluid opcodes are better for using SoundFonts as they were designed to 
be used, as organized ensembles of keymapped samples.

The other opcodes can be better for access to individual samples, and more 
detailed control from the Csound orchestra language.

Regards,
Mike

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


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"




----- End forwarded message -----




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