GlobalDictionary

Design

  1. We need a global instance of TTDictionary.
  2. Objects anywhere can access the values by name.
  3. Make a Max wrapper (analogous to the Max 'value' object)
  4. Make the variables recognizable by parameter/message/hub/etc.

Original Correspondence on Jamoma-Devel

It would be nice to tie it into one of max's variable systems - like pvar, named objects, or pattr. i understand that this might cause cross-platform issues, but it would be very convenient.

If you just did it within the cue script, you couldn't update it dynamically.

It seems as if a text pre-processor for the jcom.send object would be a way to go. It would look for the variable designator and replace it with the variable before passing the command along.

[> 1.7] <- number object named "bob"

/filter/freq $bob

In your solution, you seem to be setting up a TTHash that would essentially duplicate all of the value/name pairs from the regular max objects. I could see that this might be more easy to make cross-platform. Is that your thinking?

perhaps bob would be a better designator? I don't think is used in max, of course it may cause some confusion in Ruby

Before I set my heart on this, would anyone else find this useful, or is there another way to approach this that I'm not aware of?

jesse
Hide quoted text -

On Mar 21, 2011, at 7:36 AM, Timothy Place wrote:

Hi Jesse,

Are these "named variables" something that are used within the confines of a cue script? Or do you envision this as a large and more integrated part of Jamoma?

If they are to be used only within a cue script, then it could be imagined that the cue script module(s) would handle lines that declare variables, e.g.
$foo = 3.1415
and then the cue script can interpret variables when it encounters them in use, e.g.
/filter/freq $foo radians

This is probably a good place to start anyway.

I can imagine a way to make it more universal, but it is more work. A lot more work:
0. We define a convention for variables (e.g. they all start with a $ or something)
1. We have a global TTHash, which maps symbols to TTValues
2. We create some new objects in Max that define these, and/or we can define them with messages in a cue script, which adds them to the TTHash
3. In parameters, messages, etc. then any message or argument that begins with special character ($ in this example) is looked-up in the TTHash and replaced.

There are a couple of problems we will run into quickly. The special character is one. The $ is special in Max already and might cause grief. Maybe ends up being :: or something? We don't want to use math symbols, because use math in the cue script to assign variables is the next obvious feature request. We don't want to use OSC-reserved chars because we want to send these as OSC messages.

Another problem is that we've just defined global variables. The cue script variables are scoped to be local to the cue script. The global variables could become a problem and we should also think about how to have variables scoped. This is important as the world moves to increasingly higher processor/core-counts and thread-counts in parallel applications.

On the upside, maybe you can set up Kickstarter campaign to fund the development of this feature request :-).

best,
Tim

On Sat, Mar 19, 2011 at 2:25 PM, Jesse Allison <> wrote:

Does anyone else have a need for being able to use variables within an osc command?

I envision something like having a named number box, pvar, or pattr object.

Then being able to use [jcom.send jcom.remote.module.to] (or whatever the newest iteration is to be) and passing a command like

/delay/time [delayTime]
/delay[delayInstance]/time 172

This may seem trivial in these examples, but when you combine this with cue scripts, it would be really powerful. For instance, I have a piece that needs to suddenly get loud and then soft at specific points in the piece, but the amplitude is controlled by a performer. If I could simply:

/output/gain 0.

WAIT 5000

/output/gain [howLoudShouldIBe]

It would save me a lot of hassle!

Along those same lines, I could see something with an array of values - sort of ruby-esque iterations.

filterNumberArray = [0,1,3,4,8]

/filter[filterNumberArray]/q 7.9

setting filters 0,1,3,4,8 to 7.9

Or perhaps a range like /filter[0-9]

I would find these types of functionality very useful. I'm rather curious what people here think

-Jesse