posted 09 April 2008 04:55            

Will it be possible to release a preset managing tool?

Something that would allow more straightforward ordering, renaming, deleting and saving of preset data for the VCS? Plus something that would allow the copying and pasting of parameters from controls of one preset to the same controls of another preset.

Is this a possibility?

what tips can people recommend with the current situation?

posted 10 April 2008 23:29            

I spend hours tediously editing a Timeline layout, then when I re-open it the next day I find that widgets have moved and changed sizes, and unused layouts that I deleted have re-appeared.

It is absolutely maddening.

The VCS looks like something out of the 1980s compared with the GUIs one can build in MAX/MSP. Please! User interface is important!

posted 11 April 2008 09:43            

The root of the problem as I see it is that hot variables are global. The VCS makes this difficulty evident, but it's a problem even without the VCS making the problem graphic. The basic composition model of sounds in Kyma is highly modular, but hot variables (and the VCS) are the other extreme: they are not at all modular.

What I have wondered about is whether it would be possible to make the VCS structure mirror the parameter structure of classes rather than hot variables. When we compose sounds, the parameter fields of the classes that make up the sound could be thought of as 'control points' within the composed sound. If there were a layer in the VCS associated with each class, and if that VCS layer refered to the parameter fields of its associated class instance, then it seems to me that much of the difficulty would go away. The VCSes would compose naturally and there would never be a name clash because each control in a VCS would refer to a unique and well-defined parameter field.

Well, it's a pretty half-baked idea but there you have it, haha.

posted 11 April 2008 21:37            

What you'd like is that as you develop a sound, you invest in the structure of the sound as well as its VCS, and that this investment is preserved somehow as you use that sound in larger sounds, or when you snip a piece out of the sound for use elsewhere. But the VCS structure is not really tied to the sound per se -- it is tied to the hot variables in the sound, but these must necessarily change and be renamed or eliminated and augmented as you compose larger sounds and decompose big sounds into smaller ones.

As I say, in my case I've been able to get a satisfactory solution by simply minimizing my use of hot variables and instead leaning much more heavily on class encapsulation, which is a much more modular construct. But I can well imagine that others have sounds that simply must have lots of hot variables to work properly...

posted 12 April 2008 09:34            

Perhaps we need a VCS which is a stand-alone object where you can organize various controls to suit your needs, and then assign the outputs of the controls to different !HotParameters.

Combine this with some Cut & Paste ability so you can re-use parts of other layouts. This would make me a lot happier.

posted 13 April 2008 04:10            

Mapping of !HotVariables with OSCulator is very easy.
I would advice specifying the global map path in the preferences first, this makes things even more easier.
To map a control, you control-click on the VCS widget, tell it what CC you want it to use and then use the same CC in OSCulator.
If the controls are defined in the Global Map, ou have nothing to do, their hot variable names are listed in OSCulator.
You just have to learn how to send OSC message from Max, but with the udpsend object, this is very very easy.

posted 21 April 2008 17:05            

Unfortunately not for the moment.
For that OSCulator should be able to read into the Flame the current values of the VCS widgets, which is not (yet, I hope) possible.