I’d like to put a voice input into psvanal, and rather than sending the whole output to pvsadsyn, divide its main frequencies and amplitudes to various other instruments.
How workable is this? – and what seems the best approach?
Forrest Curo
San Diego
Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Hi Forrest,
I can think of two approaches: using pvstrace to obtain the n strongest bins and work from there.
Or use pvsftw pvsftr and use other analysis mechanisms to find the frequencies and amplitudes from there. Probably not really good for extreme live usage.
I am not quite sure whether the track tr* could be of further help.
HTH.
Best wishes,
Jeanette
Feb 6 2022, Forrest Curo has written:
um, pvstrace gives me another f-variable with the bins I want. What I want (from each individually) is it’s frequency and amplitude, so I could plug those into instr 11, instr 12, … [I may be missing something obvious here?]
pvsftw should give frequencies and amplitudes, which is what I need. So if I read the first N values of these, that should suffice for N instruments. “Extreme live usage”? Probably using pvsmooth? – refreshing the frequencies at something like 100 times a second, maybe, rounding the values to 1/2 steps to (I hope) minimize the need to trigger new notes.
Might work?
Forrest
It looks like I should use pvsmooth, pvstrace (so I’ll know how big to make the tables), pvsftw, in that order, then periodically read those tables to get frequency and amplitude values that might be stable enough (?) to use.
Thanks, at least it makes theoretical sense… The rest is tinkering, um!
just to note that there is also pvs2array/pvsfromarray (or in old terms: pvs2tab/tab2pvs) which i personally prefer compared to pvsftw/pvsftr:
https://csound.com/docs/manual/pvs2tab.html
https://csound.com/docs/manual/tab2pvs.html
best -
joachim
Feb 7 2022, Forrest Curo has written:
It looks like I should use pvsmooth, pvstrace (so I'll know how big to make
the tables), pvsftw, in that order,
...
The f-table needs to be the size of your f-signal, which is set with
pvsanal or something similar. It might still be a lot easier, if you
precede pvsftw by pvsmooth and pvstrace, since the resulting f-table
will be a lot cleaner and easier to work through.
pvsftw has a flag that is set when new data is written. I think this
happens every f-rate cycle. If absolute timing is not that important,
you could just read the f-tables every 100ms or whatever you set the
pvsmooth to. This should work fine.
Best wishes,
Jeanette
After pvstrace fsigin, kn… Don’t I have an fsig with kn bins to go into karray[0], … karray[kn - 1] ?
Or have I missed something here?
Feb 7 2022, Forrest Curo has written:
After pvstrace fsigin, kn... Don't I have an fsig with kn bins to go into
karray[0], .. karray[kn - 1] ?
AFAIK, the fsig has still the origina number of bins, most are simply 0 now.
Best wishes,
Jeanette
Ah! I can specify an array with pvstrace, and know
"kBins[] – an array of size fftsize/2 + 1 values, whose first N values report the kn bin numbers retained by pvstrace. Other locations are set to 0. It can be sorted or unsorted."
Those bin numbers, then, would not be the amplitudes nor the frequencies, but their indexes in the arrays pvsftw would produce?
Feb 7 2022, Forrest Curo has written:
Ah! I can specify an array with pvstrace, and know
*"kBins[]* -- an array of size fftsize/2 + 1 values, whose first N values
report the kn bin numbers retained by pvstrace. Other locations are set to
0. It can be sorted or unsorted."Those bin numbers, then, would not be the amplitudes nor the frequencies,
but their indexes in the arrays pvsftw would produce?
That's the way I read it. As suggested you might want to consider using pvs2array if you want to control the other instruments from the instrument running the FFT analysis dynamically. If everything can be set up fixed pvsftw might suite you better. I find f-tables to be more flexibly managed between different instruments. A question of taste or style though.
Best wishes,
Jeanette
“I find f-tables to be more flexibly managed between different instruments”
Would that mean somehow dividing an f-table between them? – running pvsadsyn, say, on different sets of bins?
Feb 8 2022, Forrest Curo has written:
...
Would that mean somehow dividing an f-table between them? -- running
pvsadsyn, say, on different sets of bins?
...
I'm sorry, I was a little confused. If you have the array output from
pvstrace, you only need N elements of that. If you launch your other
instruments from this one, using any of the schedule or event opcodes,
that is fine. If the other instruments are already running or launch
elsewhere, you can copy the first N elements from the output array to
another global array or create an f-table and use something like
copya2ftab.
Best wishes,
Jeanette