Hi,

I've removed the "highly" adjective =). But though the use of the fluid
opcodes is recommended (I think I wrote that because of endianess or
64-bit problems with the old opcodes), they are by no means deprecated.
It is merely a suggestion.

Cheers,
Andrés

El vie, 18-01-2008 a las 16:36 -0500, aaron@akjmusic.com escribió:
> 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"