Storing with the conductor : a fragile solution ?

[La Tenaille]

Hi,
I'm wondering about the conductor storing function.
For example, let's imagine that in a patch I create 10 faders that have different adjustments for each conductor preset.Then I store every positions with the conductor (hours of work). Now let's imagine I want to move my patch to another place in the patch grid : does it mean all my work is lost ? And if, for any reason I want to change for 10 knobs insted of 10 faders : my work is lost ?

[nay-seven]

humm, i'm afraid that yes for the 2 situation...
conductor is here to help you to store any of your changes....

[La Tenaille]

well, then perhaps I'd better look for another way to store my adjustments.
I thought about the preset manager as an alternative but it seems to have the same limitation : if I put a knob on a VST parameter for example, then store its state with the PM, and then delete this knob to replace it with a fader, the stored adjustment of my VST is lost. Perhaps I'd better forget the possibility of remoting my VSTs with knobs and faders ?
I also use switches remoted with my MIDI pedal board (MIDI learn, toggle mode), and the initial state of these switches are changing from song to song. I'm afraid the problem will be the same...
Any advice welcome

[cmodica]

I think the better way is to built the patches and interface, then test, then make the correction and after add some PM or Conductor. So if you change something it will be just a little think and you need just a few second to do it .... That is the way that i use to do.

[La Tenaille]

Hi Cmodica.
That's what I've done. Then 20 snapshots with the conductor, including a PM on a patch snapping VSTs (that's just a begining, I plan a lot more toys ). The thing is, if I want to change... let's say a knob for a fader ; it means I have to note its position for each preset before replacing it. And I must have about about 20 controllers with stored positions, and I'm about to start a second workspace for another band, that means a huge number of controllers at the end...
I've already changed my aproach about 10 times since I've started using Usine, and nothing will convince me I wont change it again at least 100 times a year
That's why I ask some help before starting my 11th approch

[cmodica]

Yes i understand ... But i don't see any solutiion ...
I hope some one else could help you.

[martignasse]

Hi La Tenaille,

The thing is, if I want to change... let's say a knob for a fader ; it means I have to note its position for each preset before replacing it. And I must have about about 20 controllers with stored positions, and I'm about to start a second workspace for another band, that means a huge number of controllers at the end...

If i understand correctly, you want to have independent control on the value stored and the way you manipulate it, right ?

The thing is, for usine the value come from a control and is coupled with it. But with Usine, nothing impossible :

So, the solution could be....to use two controls, one for storing (a fader, for example), and one for manipulate (fader, or knob, or what you want). Like that, you can replace the 'manipulator' control without killing the preset (who store the value of the 'ref fader').

something like that :


and in the subpatch :


in interface builder :

You can manipulate the value with the knob, make some presets, replace the knob by a slider, and you always have your preset

Hope it help ?

[Vincent]

... and for clear patching, you can also put the 2 'pass if chge' IN the subpatch, if connected to data in/outlets, they work the same (in and out values are marked in red in the patch interface, meaning 'only if change').

[cybercharles]

Hi

thanks ! very useful tips !!!

See U

Charles

[La Tenaille]

Hi,
Thanks Martin for this clear answer
I need now to understand and meditate the the deep logic of Usine

the value come from a control and is coupled with it

My trouble seemed to be a story of master/slave, that's it ? If I plug a fader before another one to control it, it then becomes master and clear the slave adjustment ?
With this tip, the conductor only stores the PM status and ignore the faders, that's it ?
Does it also means when I change adjustments with my "superficial" knobs, I must first store the changes with the PM before storing with the conductor ?
Thanks again for the brilliant demonstration

[Vincent]

Hi Latenaille!

When you say «superficial knobs», does it mean «knobs in the parent patch»?

Your question is not an easy one and can be answered in different ways according you want to do.
First, all the controls values in the parent patch will be stored in the conductor's scene. So if you have there a PM, or even a fader that determines the preset# in a PM that is somexhere else, it's value will also be stored, except if you tick 'do not store with conductor/preset manager' (right click, you know). Remember this usefull oprion.
(I would like to make screenshots, but my connected computer is not the one I use as DAW...)
So, that means you really have to think aout your actual needs, keeping in mind that you might discover in a couple of weeks that you have to change your needs!
I usually put the PM in a sub patch, side by side with the VST I want to control with it, and in that sub patch, I drop NO interface design but only data inlets/outlets. If I know I'll have to change the presets, I add dataInlets to be able to store my changes from outside (and the 'store' button in the parent patch is NOT stored in the conductor!)
Starting at this point, my solution can be unuseful for you, since I then use the sequencer to change a fader (wich is not stored un conductor too) that sends values to the subpatch PM. Maybe you'll wish to store also this fader values and, if you do this, that means that the PM could as well been dropped directly in the parent patch!

Just remember this:
If you drop the PM in a subpatch, it's values won't be stored in the conductor. BUT the same can be done in dropping it in the parent patch and setting it not to be stored in the conductor...
SO... you have maybe to consider different functions of the PM and clearly know which of them you need to store in the conductor or not. And why, I mean: according to which need.
In few words:
Put the PM in a subpatch and put inlets (and related controls in the parent patch) for only the values you want to store in the conductor
OR
Put the PM in the parent patch and leave it storable in the conductor but add some controls not storable in conductor (and fortunately PM!) if you want some parameters of the PM not to be changed by a scene change (don't slip any 'PassIfChge' in between!).
Since the PM has only a very few controls, you'll find that the answer is finally easy.

Your idea of "master/slave" is not bad.
Think of it in terms of data flow. Just like rivers: what is "upstream", what is "downstream". And how does it "run out".
And be patient, all that stuff will progressively be natural for you.

[La Tenaille]

Hello Vincent,

When you say «superficial knobs», does it mean «knobs in the parent patch»?

That's it. It's my romantic side

in that sub patch, I drop NO interface design but only data inlets/outlets.

I had never considered the data inlets/outlets. That's a new interesting approach for me !

I've made a few tests, and thanks to your explanations, things are getting clear !
In Martignasse example I missed the storing of the PM with the conductor, so I've added a fader to the subpatch PM number inlet, set it visible in the interface, and it works
The thing I don't understand is why is it stored in the conductor, as the fader is in the sub-patch and not in the parent patch ?

A last little ergonomic trouble : with this solution, I have to leave the interface and open the patch, then the subpatch to rename a preset. Not ideal with an instrument in my hands. Any idea to do that directly in the interface ?

Thanks a lot

[Vincent]

Hello La Tenaille
Yes, I've noticed you are an artist!

The thing I don't understand is why is it stored in the conductor, as the fader is in the sub-patch and not in the parent patch ?

I'm not sure I exactly see your patch.
Just for confirmation, you have a patch X with controls visibles in the interface builder window (IBW) and a subpatch Y in wich you dropped a PM (and a VST)?
The conductor will store any control value in the X patch (assuming "dn't store in conductor/PM" is unticked).
The PM will store and control value in the Y patch, including VST tuning and excluding "dn't store in conductor/PM" controls.
If the value of the PM can be changed with a fader in the parent patch (X) how does the data come into the subpatch Y?
If you use a fader in the subpatch instead of a DataInlet (note: you can find a 'DataInlet' in the drag+drop wiring menu!):
A) the value of that fader will be stored in the PM. In other terms, the PM will store it's own value for each preset, wich is a non-sense;
B) the parent preset number fader will be stored in the conductor, transmitting its value to the children preset number fader (in Y) whose value is stored in the PM. => it works just as if the PM value were directly stored in the conductor, that is: just like if it were simply dropped in X (parent patch). Besides, something else can happen: you store the Y PM value in a preset and, of course, when you call that preset, it recalls that value. => if you're not very attentive and you store a 'Preset A' with the value of a 'Preset B' in the fader, you can understand that 'Preset A' will subsequently recall 'Preset B'!
To avoid that mess, use data inlets! NO interface design in the Y patch (subpatch) unless you really want to store their values in the PM. If this PM usage is only for VST, its OK like this.

A last little ergonomic trouble : with this solution, I have to leave the interface and open the patch, then the subpatch to rename a preset. Not ideal with an instrument in my hands. Any idea to do that directly in the interface ?

Yes, that's true.
Personnaly, there is monthes I gave up giving names to presets in subpatches. I really don't care, since I never see them: it's just "inside the engine" and I forget about it (as long as it works )
Since most of my PM are in sub/subpatches and often driven by a subpatch PM (or via busses), I've also tryed to give names using buttons and text fields in the parent patch. With no success. Anyway, naming a preset, even directly with no subpatch and things like that, is not very easy with an instrument in your hands!
So, I just forget about preset names. Certainly other guys may have good tricks I did not think about! Perhaps by choosing to display it in the parent patch? Never tryed...
I have a fader to change the preset#, a button to store changes made in the current preset and a button to show the VST interface. I display it, tune it, then store. I don't even know where it is in my workspace. I just don't give a sh... As you'll understand: "Basta cosi". Sure I can see big blocks of "recall preset: no name" in the trace panel... Who cares in the audience?
You are a musician: just make it sound!

Hope I'm not too confuse...
Cheers

[La Tenaille]

To be clear, here is my 'experimental' patch (my DAW is not at home) :

The PM stores its own preset value and it's a non-sense but I need to control it from the IBW.
As you can see, no PM controls in my parent patch, and the conductor stores the PM preset number... weird ?
Or perhaps I (once again) miss something ?

PS : the 'pan 1' fader is not stored in the conductor, I've just made a last minute modification

[Vincent]

Hello La Tenaille,

As you can see, no PM controls in my parent patch, and the conductor stores the PM preset number... weird ?

I think it's because the preset number appears in the Interface Builder. The conductor must store the 'preset' fader value.
Right-click on it and choose "Not stored in conductor/preset".
The reason to put the PM in a subpatch is that there is no "Not stored in conductor/preset" for a PM.
I hope i'll run!

[La Tenaille]

Hi,
In fact, I want the PM number to be stored with the conductor. Do you think the PM storing its own preset fader is a problem ? Because it works...
The interesting thing I learn here is the conductor stores the IBW values, even if the related controllers are in a sub-patch !

As I'm quite curious, I've tried the same thing with a local stand alone interface window in the sub-patch, and it isn't stored. The same thing if the local interface is in the main patch, even if I it's displayed in the parent IBW... mmmmm...

[Vincent]

Hi La Tenaille

In fact, I want the PM number to be stored with the conductor.

So, why to drop it in a subpatch?

Do you think the PM storing its own preset fader is a problem ?

I don't think so. It's just an unnecessary redundancy. I don't see any situation where it can be a problem.

I've tried the same thing with a local stand alone interface window in the sub-patch, and it isn't stored. The same thing if the local interface is in the main patch, even if I it's displayed in the parent IBW... mmmmm...

as you say: mmmmmmmm. I'm learning too!

[La Tenaille]

So, why to drop it in a subpatch?

... to follow Martignasse example. But it's perhaps useless ?

[Vincent]

Ok La Tenaille, I re-read the thread from the beginning!

There were two questions:
1) be able to move a whole patch without loosing the tenth of adjustments you made and you stored in the conductor.
2) be able to replace faders by knobs and so on without loosing the tenth of scenes you stored.

For the second question, I have no answer. Maybe one day the interface design modules will be indexed in Usine and we'll have access to this index (like in Reaktor).

For the first point:
If you want to move a whole set of controls AND some kind of memory of their values, you can use a PM dropped in the same patch. When you move the stuff, you also move the presets.
OK. Well done.
The thing is that you'll have anyway to rebuild the scenes in the conductor. Conductor will store new/moved presets values.
The primary purpose was to move your patch without being obliged to redo all the adjustments and rewrite each scene. You'll have to rewrite the scenes anyway, but thanks to the PM, the adjustments won't be lost.
When done, why to care anymore about the PM since it's just there in case you want to move a patch and it's adjustments?
Just think of it this way.
So, when patching you'll have to follow the right method:
1. recall the scene you're going to re-patch.
2. move the patch (with it's adjustments stored in the PM!)
3. be sure to recall the right preset for that patch and that scene (it could have been changed to a wrong one in step 1)
4. then rewrite the scene
I think thats all since now you won't matter who from the scene or the PM is doing the right adjustments. Right?
The point is that it's sure you'll have to change some adjustments anyway, just because they are not covenient for any new situation.
Let's imagine you do this. What will happen?
If you rewrite only the scene, these adjustments will be stored in it, but not in the PM. And, if you wish to move that patch one more time, "you have it deep in ze c..."!
Meanwhile, storing new asjustments in two different places is a potential source of trouble.
It seems to me that you can avoid this mess in asking the PM to re-store each time you rewrite a scene. I've never did this.
My idea would be to use Audio&DataBusses, with no loop.
Let's look at it:
1. Have a conductor module in a track wich is always active (it can be in the master section, BUT be aware that you may sometimes open WKP that have no scenes...).
2. Connect a SendToAudioBuss to its 'rewrite' outlet, maybe with a 'waitonecycle' to be sure, I'm not sure it's necessary. Let's call that bus 'RewriteAllPM'.
3. In the VST patches, drop and connect a GetFromAudioBuss to a PassIfChge, then to the 'store' inlet of each of your PM, and name it 'RewriteAllPM'.
It seems to me that this solution makes PM transparents and you don't have anymore to take care of them. They just do their work in background, archiving the patch(es) values just in case you'll have to move it (them) later.
This way, I don't think you need to drop the PM in a subpatch. It's up to you to display it or not.

Sorry for this winding thread!
Is this an answer?

[woodslanding]

I'm not sure I understand all the details of this thread, but here's my solution. I've decided I have to separate the view from the data:

My interface objects are all data-independent now. I actually have a grid of buttons in the touchscreen that can function in many different ways, and they are all controlled and read by a script, and dynamically change their titles (and value lists, thanks to the comma data input!) via script depending on various MODE buttons. I have 64 buttons and 4 combo boxes (tied to encoders on my controller.)

The actual data is being stored in an array. I've taken all the data that's associated with a preset, and store it in (and read it from) this array. I'm hoping the 512 limit will go up, but I'm not too close to it yet. And I could split the data out to multiple arrays if it seems like a problem.

So I don't store any of the states of the interface objects in the conductor. The only thing I store is the array. And I control via script what gets written and read from the array. I could even create a script to write all the presets to a text file. Or XML if I wanted. Someday I could code the interface in flash and send the data to Usine via OSC from a database.

now all usine has to do is store and recall all the values in this array, and do the midi, routing and audio control associated with it. And if I create a new object that needs a value recalled for each preset, I can give it a personal spot in the array, and it will always be remembered.

Basically, this is kind of like Reaktor tagging, I guess.

Don't quite know if this is going to work, but that's how I'm proceding. And I don't suppose it's much help to anybody else, but it might get you thinking

-e

[Vincent]

Hello La Tenaille,

Well, I just say... wow!
It seems big!
Separating view and data like you did, sure it's quite new in Usine.
Bye-bye conductor...

Cheers

[woodslanding]

Oh, I still need the conductor.... for now.

[Vincent]

Me too! I've not planned to build by myself any alternaltive solution.
And I don't want Olivier to suppress it...

[La Tenaille]

Hi guys,
My wife has been hospitalized yesterday and I'm stoping Usine for a while.
Thanks for your help, I'll be back as soon as things will go better.

[lucenay71]

hello
i'm a beginner with usine pro: I 've got some trouble :
My sound card is a M -Audio firewire 410 and i get some crash with the m-audio asio, i ve changed for Asio4all and it works better but i get some clics with vst absynth 4 and FM8 in sequencer mode. More I've some problem with tHe Fm8 which doesn't work i think it is a midi failure but i don't see what . I wonder if i've expressed myself clearly ? can you help ? moreover no problem with Usine Vst .
thanks a lot

[Vincent]

@ La Tenaille
As we sometimes say in french: "Thousands of good things for both of you".
Hope everything will be absolutely OK.

@ lucenay71
I can't help you for the m-audio firewire 410 issue, but I 'lm surprised you had to used Asio4All.
I can say two or three things about Absynth4 I use in sequencer too.
It sometimes needs a lot of resources, sometimes not (with se same bank, I mean). You don't see it anywhere except in the Perfomances Window of Taskmgr.exe. Just reload the WKP and it's fine.
And maybe Asio4All could do that too, I had bad experience with it. But you have a good card and you should'nt have to use Asio4All.
Does the Program Change work fine with you?

[nay-seven]

@ la tenaille : many lights for you and your wife...