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

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



Hi Julian,

That is simply a matter of perspective.
The point is that you are moving back and forth between node objects, osc commands and events. In terms of language side constructs, events have the most general range of application.
So, if you use events only, you have internal consistency.

As you pointed out, the problem is having control names indicate update rate, which is a bit of a false economy.

RJK

On Feb 29, 2008, at 10:07 AM, Julian Rohrhuber wrote:

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


--





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