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

[sc-dev] Re: Some 3.3 work

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

> 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

> 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.)


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/