|
I've written the following csd as a kind of "proof of concept" for what i'm
thinking (with some minor adjustments) could be a vectorial opcode that
allows for custom "slew rates" applied to changing table values, with
independent "up & down" interpolation rates, depending on if table values
are currently increasing or decreasing, compared to the current values.
I used a portk type of approach to model the concept because it was the
easiest to implement. (i threw this up very quickly this afternoon) - "rates
of increase / decay" would provide a more controlled approach...
I've written some introductory remarks as comments in the csd itself that
explain what i'm trying to do, & the types of concepts i'm trying to
explore.
I wonder if there's not an easier (existing) way to go about this?
given the vectorial / table based nature of the application - is there
justification for implementing this type of thing as an opcode?
it's an idea that i've had in the back of my mind for sometime, but i'm now
finally devoting more of my time to designing some instruments in csound (as
my python based compositional undertakings edge ever closer to the "ready
for execution stage"... & my dissapointment with sample based orchestral
libraries is beginning to wear out many of the options i hoped to explore
there.. largely because no bugger seems to have worked out that divisi
strings in an orchestral library might actually be a jolly useful idea -
what will i do with my vertical 6 member pcset aspirations now? ; ) )
anyway - what do y'z reckon out there anyone? (& those interested in
assisting / discussing please read the ;;; commented explanation in the csd
below)
cheers
Tim
sr = 48000
ksmps = 64
nchnls = 2
0dbfs = 1
seed 0
;;; ************************************
;;; uses a process synonymous with portk
;;; to apply krate smoothing
;;; to table value transitions
;;; allows for separate defineable slew rates
;;; in the upwards & downwards direction
;;; the suggested application is 2 fold:
;;; 1 - to smooth the addition / subtraction of active partials
;;; in modulateable additive synthesis (using adsynt)
;;; 2 - to create something synonymous with pvsmooth
;;; but that allows for rapid increases of amplitude
;;; but slow decays of amplitude
;;; two additional ftables could then replace the global
;;; slew up & slew down rates
;;; (giuprate & gidownrate below)
;;; this would allow for arbitrary definitions
;;; across the spectrum
;;; of spectrally based "sympathetic resonance"
;;; in response to table based pvx, or adsyn style "excitation"
;;; the aim being to produce
;;; quasi-reverb / convolution-like / "sympathetic resonance" effects
;;; driven by the values in the excitation signal data/ analysis
;;; the extent to which this overlaps with
;;; existing fft / impulse response/ convolution style processing
;;; im not sure
;;; if i could define impulse responses
;;; based on this kind of "spectrum vs rolloff time" information
;;; then i might forego this second
;;; (& possibly most interesting)
;;; application scenario
;;; in favour of a "spectrally defined impulse responses" approach
;;; how difficult would this custom "reverse engineered IR definition"
;;; be to achieve?
;;; i.e i would define decaytimes as Y axis range values against freq values
on the x axis domain
;;; ************************************
gipcount init 8
gi_responsevalues ftgen 10,0,gipcount,-21,1,60
giuprate = .6
gidownrate = .001
giresponseaudio ftgen 12,0,gipcount, -7, 0,gipcount,0
giratios ftgen 13,0,gipcount, -2, 1,4,7,10,13,16,19,22
giamps ftgen 14,0,gipcount, -7, 0,gipcount,0
gisine ftgen 1, 0, 16384, 10, 1
;;; *****************
;;; *****************
;;; the driving force
instr 100
gi_drivingvalues ftgen 11,0,gipcount,-21,1,60
iindex init 0
dBinit:
ival table iindex,gi_drivingvalues
ival = ival*-1
print ival
tableiw ival,iindex,gi_drivingvalues
iindex = iindex+1
if (iindex < gipcount) igoto dBinit
ftfree 11, 1
turnoff
endin
;;; *********
;;; *********
;;; the symathetic result
instr 101
iindex init 0
dBinit:
ival table iindex,gi_responsevalues
ival = ival*-1
print ival
tableiw ival,iindex,gi_responsevalues
iindex = iindex+1
if (iindex < gipcount) igoto dBinit
kindex = 0
loop:
kinput table kindex,gi_drivingvalues
kresponse table kindex,gi_responsevalues
if kinput < kresponse then
kdiff = kresponse-kinput
kdiff = kdiff*gidownrate
kresponse = kresponse-kdiff
else
kdiff = kinput-kresponse
kdiff = kdiff*giuprate
kresponse = kresponse+kdiff
endif
tablew kresponse,kindex,gi_responsevalues
if kindex == 0 then
printk2 kresponse
endif
kamp = ampdbfs(kresponse)
tablew kamp,kindex,giamps
kindex = kindex+1
;;; for audible clarity of concept only the first bin is output
;;; rises in amplitude occur quickly
;;; decaying amplitude is slower
;;; if (kindex < gipcount) kgoto loop
asig adsynt .25,440,gisine,giratios,giamps,gipcount
outs asig,asig
endin
i 100 0 1
i 100 + .
i 100 + .
i 100 + .
i 100 + .
i 100 + .
i 100 + .
i 100 + .
i 100 + .
i 100 + .
i 100 + .
i 100 + .
i 100 + .
i 100 + .
i 100 + .
i 100 + .
i 100 + .
i 100 + .
i 100 + .
i 100 + .
i 100 + .
i 100 + .
i 101 0 30
e
-----
*******************
www.phasetransitions.net
hermetic music * python * csound * possibly mindless ranting
various werk in perpetual delusions of progress....
--
View this message in context: http://www.nabble.com/%22vecportk%22-opcode----approaches-to-%22spectral-resonator--convolution%22-tp16415195p16415195.html
Sent from the Csound - General mailing list archive at Nabble.com.
|