TTBlueMeetingInGenoa

#summary Topics for discussion during the TTBlue meeting surrounding the upcoming NIME conference in Genoa, Italy.

Attributes, Methods, and Accessors * the prototype for attr accessors: flexibility vs. usability. * related to the above, whether or not to make attr accessors public instead of private as suggested by Dave. * attribute properties (built-in clipping, etc.)

Tim likes the idea that they are private and that all calls go through the message passing interface, because that means that if anything changes regarding the presence of an accessor or how it works then no changes will need to be made in the calling code. However, it would be nice for performance reasons to have direct access to the accessors, so I can see it both ways.

If we do want to call accessors directly then we really need to get rid of the dummy attribute that we currently have to pass to an accessor. We still want the ability for an accessor to receive the attribute object if needed though -- to find out about it's clipping ranges etc. So I think this means that the attribute object needs some flags that indicate what kind of accessor it is calling: A 'simple' accessor flag would indicate that the TTAttribute object is not passed.

Should attribute properties themselves be implemented as attributes? Should the Attribute then be derived as a proper TTObject?

Processing and Algorithms * mechanism to process one "sample" such that units can be used to do simple calculations of the form y = f(x) * migration of Jamoma FunctionLib into TTBlue

This topic came up during a Skype between Tim and Trond. The idea is that an object could have a method that would calculate a single value using the algorithm. In audio terms, it would calculate a single sample rather than a block of samples. If the object did not define such a method, then TTAudioObject would define a default method which would wrap the single-sample input in a TTAudioSignal and send it to the normal process method.

One example of an application of this is the Jamoma FunctionLib. If we created a TTTanh object in TTBlue, then it could process the single value required by Jamoma's FunctionLib, but also could process audio in TTBlue. Likewise, an object like TTOverdrive or even TTLimiter could be used by Jamoma's FunctionLib. A FunctionUnit in Jamoma is then simply any class that derives from TTAudioObject.

One question to resolve is what to do about the 'multichannel' aspect of an audio processing method. Should the input and output for this new "calculate" method pass in/out a single value? Probably we will use TTValue, which means that it could contain a list. What do we do then? There should be some thought about this.

Instantiation * class naming * class factory * class searching -- the notion of specifying tags for TTBlue classes, and accessing lists of classes by querying for a tag * deleting an instance safely

There is a crude notion in TTBlue of naming a class with a TTSymbol. It is not very organized or well thought out. The reason that this is useful is currently best illustrated in Jamoma's FunctionLib -- if you are passes a TTObject* then you can query it to find out what kind of object it is.

Another place it could be useful to have these names is to create objects dynamically. Something like this: {{{
// create a stereo degrade object
TTObject* anObject = TTFactory.create("degrade", 2);

// or should it be this?
TTObject& anObject = TTFactory.create("degrade", 2);
}}}
This implies that objects would need to somehow be added to a registry of classes that the factory would know about. How should we do that? Manually maintain it? Some magic macro that Dave might have up his sleeve that we put in each class file?

If we can create objects dynamically in the library, without needing their header files, it serves to reason that we would need a way to find out what objects are available to the factory. If there is a registry, then it seems quite straight-forward to return a list of everything in the registry. That probably isn't as useful as getting all of the objects meeting certain criteria. So it would be nice if objects could be given tags. Then we could run code like this: {{{
TTValue tags;
TTValue results;
TTErr err;

tags0 = TT;
tags1 = TT;
err = TTFactory.search(tags, results);
if(!err)
// results contains a list of TTSymbols with the names of the relevant classes

}}}

Again, maybe Dave has a magic macro to do this in each classes file? That would be nicer than having to do it all in one central file, or having to do it every single time the constructor is called (see below for info on class initialization though).

As for deleting an instance safely, we have a case-study in this problem in the Jamoma RampLib / FunctionLib. The problem here is that we want to replace an object with a different object, and the function freeing and creation occur in a different thread than the function doing the calculations. We don't want to put critical regions around the function doing the calculations because it is performance critical real-time code.

So to address this, we could add a couple more methods to the factory, assuming it seems sensible: {{{
TTObject* anObject = TTFactory.create("cosine", 2);

TTFactory.replace(anObject, "tanh");

// eventually, when we are all done:
TTFactory.free(anObject);
}}}

What would these do? Internally we could give every object a 'busy' flag. Then the freeing function could use a light-wieght spin-lock mechanism, like this: {{{
bool TTObject:waitUntilNotBusy() {
TTUInt32 startTime = TTGetSystemTime(); // This function doesn't exist yet
TTUInt32 currentTime = startTime;

while((time - start) < maxWaitTime){  // maxWaitTime can be a member of TTObject
if(!busy)
return false; // false means that we are not busy anymore
currentTime = TTGetSystemTime();
}
return true; // true means it is still busy
}
}}}
Interface improvements, Optimization * constructors doing the same thing over and over * Where is the coding interface clumsy or ugly? What can we do about it? * Infrastructure: take a look at core classes. Discuss what they are there for and see if it all still makes sense.

For example, right now I'm thinking about how Max copies the things that are the equivalent of the "this" pointer into local variables for perform routines. It does this so that the member accesses are instead being accessed from registers. I don't know now C++ does this though.

Currently there is a lot of repetitive work in the constructors of a TTObject. For example, every instance of TTDegrade is going to have the same attributes and messages. But we still set that up from scratch each time the constructor is called. Perhaps we could have a static init() method that would be called by the constructor that could do all of this work just once. But how should we implement that with the way TTAttributes need to be created, etc. Should we just forget it? Is this an argument against turning TTAttribute into a proper TTObject?

Using TTBlue * ObjectiveMax and querying/wrapping classes as Max objects in an automated way * Do we need a roadmap? Are we interested in publication? We could start now for next year's DAFX, or AES, or ??? * Tutorial or guide for the Wiki on how to write a TTBlue class and why you would want to? Can we answer the question of "Why would you want to?" * How do we concretely describe TTBlue in one paragraph? In one sentence?