There's probably already another way to do this that I've missed but if not, it would be great to be able to fold and unfold separators in the control panel.I envision folding a separator would fold all parameters below the separator until the next separator.
This would make managing huge lists of parameters way easier.
I am working with a list of about 600 parameters in the control panel right now and it is easy to get lost and scrolling is slow.
Then also if you had a trillion modules with control panel parameters, you wouldn't have to put every single one slightly lower than than the last to keep the order in the control panel, this could just be per seperator.
Another thing that would be nice is a way to select multiple objects for moving without having to shift-click each one.
Folding Control Panel Separator
maybe the invisible function...?
If I get what you are saying, then no.There are hundreds of faders that I am using to set pages of recallable labels and font colours in the interface builder. I need access to all of these hundreds of preset recallable parameters at least untill I have finished programming the presets and then I don't care if I ever see them again, at which point I will simply not open the sub patch.
If there's something else invisible does, then I guess I don't know what I am talking about
If there's something else invisible does, then I guess I don't know what I am talking about
Maybe instead of folding separators there should just be folders...
I think the invisible-approach is the way to go.
If I understand you correct, there's a set of hundreds of faders in a patch that also contains other interface design modules. After you wish not to see this set of faders anymore, there's still other things you do want to see from that patch / track? Because otherwise you could naturally just have a local interface window for that patch and close that window once you're done.
But if this is the case then invisible is the only solution as far as I know.
Not to make the patch a mess I would probably opt for the new IML system. You can arrange things in sub-patches for clarity if you wish and still be able to affect the visibility-value for each and every module you want with an IML-script. This can happen with one button press.
Make a simple test to try it out:
Make a patch with a set of 5 faders, set the visible to interface builder and arrange them as you wish. Right-click each fader and give it a name (with no white-spaces) like FADER1, FADER2, FADER3....
Now add a SendUsineMsg-module and type in this script:
SET_TARGET_PATCH SENDER_PATCH
SET_VALUE FADER1 visible 0
SET_VALUE FADER2 visible 0
SET_VALUE FADER3 visible 0
SET_VALUE FADER4 visible 0
SET_VALUE FADER5 visible 0
Now, when you trigger the SendUsineMsg-module it should make invisible all the faders. You can make another similar module but change all the 0's in the script to 3 - then, when you trigger this one, they should all re-appear into the interface window.
I didn't test this cause I'm on the wrong machine.
If you place these faders into a subpatch etc. you might have to adjust the SET_TARGET_PATCH accordingly so IML finds the faders in question...
Try it out, let me know.
antwan
If I understand you correct, there's a set of hundreds of faders in a patch that also contains other interface design modules. After you wish not to see this set of faders anymore, there's still other things you do want to see from that patch / track? Because otherwise you could naturally just have a local interface window for that patch and close that window once you're done.
But if this is the case then invisible is the only solution as far as I know.
Not to make the patch a mess I would probably opt for the new IML system. You can arrange things in sub-patches for clarity if you wish and still be able to affect the visibility-value for each and every module you want with an IML-script. This can happen with one button press.
Make a simple test to try it out:
Make a patch with a set of 5 faders, set the visible to interface builder and arrange them as you wish. Right-click each fader and give it a name (with no white-spaces) like FADER1, FADER2, FADER3....
Now add a SendUsineMsg-module and type in this script:
SET_TARGET_PATCH SENDER_PATCH
SET_VALUE FADER1 visible 0
SET_VALUE FADER2 visible 0
SET_VALUE FADER3 visible 0
SET_VALUE FADER4 visible 0
SET_VALUE FADER5 visible 0
Now, when you trigger the SendUsineMsg-module it should make invisible all the faders. You can make another similar module but change all the 0's in the script to 3 - then, when you trigger this one, they should all re-appear into the interface window.
I didn't test this cause I'm on the wrong machine.
If you place these faders into a subpatch etc. you might have to adjust the SET_TARGET_PATCH accordingly so IML finds the faders in question...
Try it out, let me know.
antwan
antwan, thanks for the detailed explanation.This does work when used with the interface builder view but for some reason I am having trouble setting the control panel view. I have set one SendUsineMsg-module SET_VALUE FADER to 0 and te other to 1 and the first time I send the value of 1, the faders appear on the control panel then they disappear fine when the 0 value is sent but only a blank control panel appears the next time I send the one value.Maybe this is a beta bug?
Otherwise the folders in the control panel would still save a lot of time because for the invisible approach to work I still have to type hundreds of lines into SendUsineMsg modules not to mention having to give hundreds of textfields and faders unique names so my feature suggestion still remains a potential time saver / workflow enhancer at least in context of the one particular task I am doing that would just be too confusing without a nice list grouped how I can see it all at once...name of destination device, name of destination parameter and destination device name font color for every available control on both a Behringer BCR2000 and BCF2000...
Regardless, I'm glad I learned about this feature.
Otherwise the folders in the control panel would still save a lot of time because for the invisible approach to work I still have to type hundreds of lines into SendUsineMsg modules not to mention having to give hundreds of textfields and faders unique names so my feature suggestion still remains a potential time saver / workflow enhancer at least in context of the one particular task I am doing that would just be too confusing without a nice list grouped how I can see it all at once...name of destination device, name of destination parameter and destination device name font color for every available control on both a Behringer BCR2000 and BCF2000...
Regardless, I'm glad I learned about this feature.
Okay, I managed to try this out myself. Although it kind of worked it also didn't 
Problem is that the fader-modules don't remember their size and positioning in the interface after they have once been turned invisible. That's not so cool, perhaps, Olivier, this could be something to change?
Anyhow, for now, check out Add-ons / Other / Tabbed panel example by martignasse.
This could give ideas for you to find a solution.
antwan
Problem is that the fader-modules don't remember their size and positioning in the interface after they have once been turned invisible. That's not so cool, perhaps, Olivier, this could be something to change?
Anyhow, for now, check out Add-ons / Other / Tabbed panel example by martignasse.
This could give ideas for you to find a solution.
antwan
Looks like I got my last post in just before you
The Tabbed panel example doesn't seem like it applies to the control panel view.That's what I'm after.
Also to clarify, in my previous post I said your technique worked when used with the interface builder, but no, it wasn't really behaving as expected like you noted.
The Tabbed panel example doesn't seem like it applies to the control panel view.That's what I'm after.
Also to clarify, in my previous post I said your technique worked when used with the interface builder, but no, it wasn't really behaving as expected like you noted.
-
martignasse
- Site Admin
- Posts: 611
- Location: Lyon, FRANCE
- Contact:
hi,
interesting discussion here
there is actually now way to dynamically control the size of a module (apart maybe with IML, but i'm not sure, i didn't investigate in it for now). That's why i made the Tabbed panel example when i was in need of managing space for lot of control, like gurulogic.
I tested the Tab trick with 'in patch' visibility, but there is some erratic comportment, it's hard to understand the logic behind.
I end up with something : Tabbed Block in patch example in Other add-ons section.
It's was kind of hard to achieve, with some erratic comportment, until i understand i have to set the visibility of all controls to 'interface builder', and all child local interface to 'parent interface', the top interface was initially set to 'stand alone window'.
Like that, all controls and positions are collected into the top parent local interface, and position can be managed easelly.
This is the top local interface (the one directly in the patch) you have to set to 'in current patch' at the end.
After that, If you have some modification or addition to do, set it to 'stand alone window 'before all, and to 'in current patch' after the modif/add.
With this method, it seems to work 'as expected' and is pretty easy to manage.
Even the Tabbed panel should work with this method and some little modifs, i'll try to adapt it.
Hope it help
interesting discussion here
there is actually now way to dynamically control the size of a module (apart maybe with IML, but i'm not sure, i didn't investigate in it for now). That's why i made the Tabbed panel example when i was in need of managing space for lot of control, like gurulogic.
I tested the Tab trick with 'in patch' visibility, but there is some erratic comportment, it's hard to understand the logic behind.
I end up with something : Tabbed Block in patch example in Other add-ons section.
It's was kind of hard to achieve, with some erratic comportment, until i understand i have to set the visibility of all controls to 'interface builder', and all child local interface to 'parent interface', the top interface was initially set to 'stand alone window'.
Like that, all controls and positions are collected into the top parent local interface, and position can be managed easelly.
This is the top local interface (the one directly in the patch) you have to set to 'in current patch' at the end.
After that, If you have some modification or addition to do, set it to 'stand alone window 'before all, and to 'in current patch' after the modif/add.
With this method, it seems to work 'as expected' and is pretty easy to manage.
Even the Tabbed panel should work with this method and some little modifs, i'll try to adapt it.
Hope it help
Martin FLEURENT - Usine Developer - SDK maintainer
-
martignasse
- Site Admin
- Posts: 611
- Location: Lyon, FRANCE
- Contact:
Ok, Tabbed panel adapted easily with this method, putted in addon->other section : here
Martin FLEURENT - Usine Developer - SDK maintainer
Hi,
Ok cool, thanks martin.
Martin's sliders_bloc add-on definately gets you kind of where you want gurulogic...
Just set the top-level local interface -module to "Top Control Panel" and try it out.
Meanwhile, you are absolutely right that there is a bug with faders not re-appearing after they've been invisible. This seems to have nothing to do with IML. Even if I make them invisible "by hand" and then set them back to control panel one by one, they never appear again. I will post this bug report once I get home tonight.
While we wait for a fix, martin's add-on is therefore the only method that works.
Regarding the trouble of making an IML script for hundreds of faders:
There's an easier way to do that. If only you don't find it too troublesome to name the faders as you create them, the rest is childplay. It can easily be achieved using IML within a regular script, by means of a for-loop. Once we get this bug fixed I can demonstrate this to you.
antwan
Ok cool, thanks martin.
Martin's sliders_bloc add-on definately gets you kind of where you want gurulogic...
Just set the top-level local interface -module to "Top Control Panel" and try it out.
Meanwhile, you are absolutely right that there is a bug with faders not re-appearing after they've been invisible. This seems to have nothing to do with IML. Even if I make them invisible "by hand" and then set them back to control panel one by one, they never appear again. I will post this bug report once I get home tonight.
While we wait for a fix, martin's add-on is therefore the only method that works.
Regarding the trouble of making an IML script for hundreds of faders:
There's an easier way to do that. If only you don't find it too troublesome to name the faders as you create them, the rest is childplay. It can easily be achieved using IML within a regular script, by means of a for-loop. Once we get this bug fixed I can demonstrate this to you.
antwan
Who is online
Users browsing this forum: No registered users and 8 guests