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

no, the thing is that in exactly this case you don't (at least you'll have to explain that in there cases there is no identity between arg names and event keys). We ran into the problem when converting a patch into event based specification. But after tracing the problem through the system for a while I'll never forget how it works..


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


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


--





.