[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[sc-dev] Re: Some 3.3 work
Hi Rohan, regarding the question where to start to count control rate
busses, I completely agree, while it is a minor change, it still can
have too big consequences when you don't boot the server yourself.
Just to clarify: the basic problem of the current implementation is
that map and set do not work the same with auudio rate and control
rate. This makes things unnecessarily complicated and leads to many
workarounds. Mapping audio rate signal from one synthdef to another
you use the In UGen and send a set message, mapping control rate
signals, you use the Control ugen and send a map message. This is not
very systematic, since in most cases within a ugen graph control rate
and audio rate work analogously.
The issue is only who knows what is an audio/ a control bus and how
is it communicated?
Josh's suggestion is that the client knows it and the server
understands it because client and server share the knowledge about
their buffer number ranges. This may indeed by a wrong assumption.
In order to follow this path, one should tell the server explicitly
the rate of a bus number one sends.
Two places are used to map controls: the extended \set message tag
(\c_), and the map messages.
For the set messages, another tag would suffice.
Regarding the map messages, a mixed (typed) message could work, where
every bus number is preceded by a sympol for the rate.
\mapa index rate value index rate value...
An alternative would be to only allow mapping control rate busses to
control rate controls and audio rate busses to audio rate controls.
The control ugen knows its rate, so it can decide what set of busses
to read off. This was what I had begun to implement, but it turned
out to be slightly more complicated.
Currently map messages do not just register a bus number somewhere,
but create access to the control bus directly. Thus it would be
better if the 'receiver' (the control ugen) could decide how to
interpret a bus number, and to have map messages store bus numbers
instead of creating a pointer.
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml