[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
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/