posted 24 December 2007 08:43            

Anyway, the thing I immediately noticed was how much easier it became to compose modules. Kyma is essentially a functional / dataflow system, with the sole exception of hot variables (! variables), and if these are eliminated, the considerable advantages of programming in a pure dataflow paradigm jump right out at you.

The downside is that that you have to restart the sound whenever you tweak a parameter. I am working by and large with relatively small wavetables, so this is mostly acceptable to me. But I occasionally put a hot variable into a parameter simply to get that parameter tuned correctly, and afterwards I replace it by the value that it finally has in the VCS.

In this approach, the VCS is therefore mostly empty. It sounds crazy, but I found the VCS to be an obstacle to the building of large sounds in a modular fashion. If the VCS had exactly the same principles of composition as the sounds themselves, this might not be so. But as it is, based on a global namespace of hot variables, it is changed with every act of composition as you build up large sounds, and if you have a significant investment in it -- in the form of lots of important values stored as VCS settings, as well as customized layouts -- then the VCS is something you have to worry about when composing modules.

I wonder if anyone else has tried this?

posted 24 December 2007 16:38            

I too use Kyma almost exclusively live these days - I used to keep lots of live variables and not use them live and like you have been setting a lot as part of the compositional process and then making VCS layouts that are large enough and colourful enough to be useful in performance. However unlike your approach, I leave the hot parameters active while composing and rehearsing, and then use the 'set to current state' (paraphrased) function to set the ones I do not want to have live in Performance.

The OO approach you are using re variables is an interesting one - I will chew it over myself

posted 25 December 2007 19:10            

Now, it may be that the advantage of this is particular to what I'm trying to do, namely, to use Kyma like a big modular synth, constantly wiring together new structures. As part of this 'functional' approach, I'm building lots of my own encapsulated classes. The parameter fields of these encapsulated classes have replaced the VCS, in effect. Using class encapsulation heavily already pushes you in the direction of less hot variable / VCS usage, since the sound structure within an encapsulated class can't have these. When I first tried class encapsulation, I found it to be a little bit cumbersome, but I have since come to be quite fast at it. I even like the restriction that you can't edit the class structure underneath the class without creating a new class, because it means that all the copies of a class must have the same behavior, so it is sufficient to attach a version number to the name of the class in order to know exactly what you've got.

posted 25 December 2007 19:25            

quote:

---

Originally posted by KX:
I prefer to store presets in the VCS since I always change my mind from day to day... perhaps I should try no hot variable to fix my mind

---

I also change my mind a lot, but now I don't think of it as changing my mind; I think of it as creating many variations on a sound. So instead of building up a longer and longer VCS that records all the changes of mind I've had, I have a sound file full of variations on a theme.

See, suppose that you build a module that you really like, and you spend a day making 20 presets for it that are really beautiful, and show off its potential. Now you are ready to go forward, and to use this module in a larger structure, putting additional processing before and after it, and maybe running many instances of the module in unison with one another.

What do you do with your beautiful presets?

You are loath to give them up, because the quality of your module depends on fine tuning of its parameters; without the presets the module isn't the same.

So, you could try leaving all the hot variables in place and going ahead with your sound-building.

One of several things will happen next. When you want to run two copies of the sound in unison, and assuming that you want the two unison copies to use different presets, you will have to rename some hot variables. But now the VCS in the renamed version doesn't work! At least one of the variables is missing from the preset. If lots of variables are involved, your preset is already destroyed.

Another possibility is that you try to compose the module together with another module that by bad luck happened to use the same hot variable name, but that needs a different value for that variable. Then you are in the same boat as the first case.

Yet another possibility is that you manage all these problems using the Prefixer or Replicator modules (although these do not solve the problem of losing presets as variables are renamed). But as your structure gets larger and larger, the VCS becomes unmanageably large. You can then use VCS operations to create sub-VCSes that correspond to the substructures in your sound, but this means that each act of composition -- wiring souunds together -- involves additional surgery on the VCS, which slows things down a lot.

Instead of all this, you could simply treat the parameter fields of the sounds as the VCS. Now you start building just by dragging and dropping. You tune by playing the sound and setting values. Introduce a hot variable to get certain parameters tuned as needed, and replace them by constants after tuning. Use class encapsulation to keep the top-level structure small.

Anyhow, this is the approach I'm trying at present, and I'm having a ball with it.

posted 27 December 2007 10:00            

in the building of realtime sound design/performance designs, a hybrid of both , a kind of optimisation of parameters that hardly change in performance should be done, of course - but it takes quite a few shows/hours to refine the decisions about which parameters should be fixed.

posted 27 December 2007 15:19            

MM

posted 27 December 2007 17:09            

- freestanding sounds when making building blocks
- hot variables and VCS when performing

Now, I still need a bunch of variations on my smaller sounds when I'm using them as building blocks for larger sounds. But I'm finding that it is quite easy to manage this as a sound file of instances of the sound, with different parameter settings. I can drag these into any context whatever with the assurance that they will behave as predicted.

When I get a complete "toplevel" sound put together that I like, then it's time to introduce hot variables, create a VCS for it, etc. The VCS is nice as a tool for building a customized control surface for a completed sound. Contolling a sound for performance is necessarily a "global" consideration; that is, it necessarily crosses the boundaries of the modules that were used to build the sound. After all, a MIDI or OSC controller doesn't know anything about the modular structure of your sound. So in that context it seems quite natural to me to use the VCS and hot variables.

-Luddy

posted 04 April 2010 13:18            

Oh My Days.... Is that what the prefixer does!!! I think the penny just dropped. I would be experimenting with this right now.. Unfortunately I am 600 miles away from home on Easter break. I knew I should of packed the Capy....

There are always some fascinating discussions that take place over Christmas and Easter holidays....... ( I always view such holidays as a good excuse to try get some quality Kyma education time in... )

Happy Easter

posted 13 April 2010 19:49            

This is in a bid to make it easier when this sound needs to be on a timeline....

On another note, is there a method to specify a VCS widget type Pentiometer not fader.. before the VCS editor? (as part of the message) I thought there might be a way....
This would also help my quest for easy timeline translation..

(Yes I later discover, this is called editing the global map)

Many thanks

Charlie

posted 13 April 2010 20:55            

Regarding cascading Prefixers, could you delete the earlier Prefixers to get the desired result? (or could you give an example of the cascading prefixer and how you wish it would work?)

posted 14 April 2010 20:27            

The actual issue.

The actual issue is I am a dumb ass.
I just wrote a whole description of my problem, which related to moving my standalone sound with beautifully crafted VCS layout to the time line and loosing the layout. I took myself through the steps to check, what I was posting. I had completely forgotten about the drop-down menu which reveals the layers of VCS setups. Duh.

I will try to spare you the prefix ramble, as it is trying to fix a problem that existed with my head. It is also nothing that can't be fixed by just using the donotchange list. Am just being lazy..

Thanks for putting up with me

Charlie

posted 10 May 2010 20:11            

Something I have never done until today!: Edited the global map and added !Attack !Decay !Sustain & !Release so that they always show up as pot's not faders on my bcf. BINGO!

Gonna have to make a much more comprehensive map...

This would be a great place to add default colour definitions for the widgets!?!?!