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

Re: [Sc-devel] t_trig cut away? bug or feature?



Hi Julian,


A little example of why I continue to pursue the idea of using events for all forms of specification - then you have consistency.

RJK

On Feb 28, 2008, at 7:43 PM, Julian Rohrhuber wrote:

it does make sense for control vs irate args, but it is confusing for
triggers. At least it should work both ways.

Yet another thing to remember.

Hard to explain.

t_trig has a very specific semantics


I think that it comes from the fact that there are two ways to
specify the type of a control. One in the name and one in the rates
arg of the SynthDef. To strip the prefix makes these two ways
consistent. But anyway it makes Events different from osc messages
and Synth objects..


Hi Julian and JAmes

This is so patterns do not need to know when prefixes are used to
spec control rates.
It is definitely a feature. But it does make the relation between
events and node classes a little
bit rocky...

RJK

On Feb 27, 2008, at 8:21 PM, Julian Rohrhuber wrote:

 SynthDef(\test, { |t_trig| Out.ar(0, Decay.kr(t_trig, 0.5) *
 PinkNoise.ar(1)) }).store;

 a = Synth(\test);
 a.set(\t_trig, 0.2)

 x = SynthDescLib.global.synthDescs.at(\test).msgFunc;

 (type: \monoSet, id: a.nodeID, t_trig: 0.2, msgFunc: x).play; //
 doesn't work

(type: \monoSet, id: a.nodeID, trig: 0.2, msgFunc: x).play; // works


 SynthDescLib.global.synthDescs.at(\test).msgFunc.postcs;

 #{ arg trig = 0; // trig!? why not t_trig?
	[ 't_trig', trig ] }
 --





 .
 _______________________________________________
 Sc-devel mailing list
 Sc-devel@xxxxxxxxxxxxxxx
 http://lists.create.ucsb.edu/mailman/listinfo/sc-devel


_______________________________________________
Sc-devel mailing list
Sc-devel@xxxxxxxxxxxxxxx
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel


--





.
_______________________________________________
Sc-devel mailing list
Sc-devel@xxxxxxxxxxxxxxx
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel