[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] Re: Some 3.3 work



Hmm... maybe:

1) add an \ar rate to SynthDef:

SynthDef(\test, {arg freq, amp;
	...
	}, [nil, \ar]);
	
2) \ar rates will be mapped to Control.ar. Control.ar can take any value that the current Control UGen takes, BUT it outputs an a-rate signal. If a control bus is mapped to it, then Control.ar has to take care of outputting linearly interpolated values between control values. If a scaler is given to it, it just outputs that value (like Line.ar).

\tr, \ir and float values will act in the same way as always. Like all SynthDef rates, the rate is non-modulatable. No code here should be broken.

IF an audio bus is mapped to the default \kr Control, then Control.kr will only read the first sample on the audio bus.

* NOT SURE IF / HOW TO DO THIS YET *

3) Bus structure remains the same. add a server messages \n_mapa and \n_mapan for node map audio an dnode map audio * n.

- in SC_Misc_Cmds add meth_n_mapa and meth_n_mapan.
- in SC_Node, add Node_MapAudio

4) Change Control UGen so if it is running at K-rate, and if Node_MapAudio is called, it just grabs the first sample. if the Control UGen has been specified as \ar, then audio mapping (etc.) is done.


Again, not sure if 3 and 4 would actually work, but I can look into it.

Rohan - any problems on your end with this? All busses remain 0 based. And if you never use an \ar rate control, then nothing should change for you.

Josh

On Dec 18, 2008, at 7:43 PM, Rohan Drape wrote:

On 2008-12-19, Josh Parmenter wrote:
why are you hard coding your busses?

because the scsynth specification states that control buses are
numbered from zero.  it is a very simple and elegant naming
convention.

In this instance you really should be using
s.controlBusAllocator.alloc(2).

but i don't always, or even often, use sclang when working with
scsynth.

Does this really break a lot of your code?

yes.  i have any number of processes (written in c, scheme, haskell)
that use c_set, c_setn & c_get to communicate with scynth.  processes
that interact with midi controllers, processes that implement physical
models, processes that co-ordinate image & sound synthesis, etc. etc.
these *all* assume that control buses are zero indexed.

Or is it something that can be changed?

of course i could re-write everything, but also of course i'd much
rather not.  and it is not as if i have made a mistake, it is very
clearly written into the specification that this ought to work.

Personally, I think the ability to map audio signal to
controls is a pretty big step forward.

i can't see it.  you *can't* map audio signals to controls, control
rate subgraphs cannot process audio signals, you need to write the
graph assuming the input is audio rate.  the proposal seems instead to
be about mapping control buses to audio inputs, ie. a notational
simplification for sclang users.  which is, of course, completely
fine.  but i don't think it justifies re-writing the scsynth rules.

If you can think of another way to get a control to know the
difference between control bus 0 and audio bus 0, please let me know.

the author tells it, either as an argument or in the method name?  as
in the example i posted?

making the a/k-rate distinction clear seems even more important in
sclang where filters do not implement implicit rate flow? just marking
a control input 'a-rate' won't help much if the control is sent
straight into a k-rate sub-graph?  (in clients that do implement rate
flow it still completely changes the cost of the graph, so again ought
to be made as clear as possible.)

regards,
rohan

further, in languages with any form of 'effect types' this shifts
initialization from a functional to an effectful setting, since it
becomes necessary to open a socket, send a message to scsynth, wait
for the reply, & handle possible errors in order to get an offset to
the zero-th control bus.


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/

******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono
*/


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/