Hi Claude,
I just wondered if there is the chance to get an optional display adjustment; I am currently working on a show where the designer used the decimal place value to of a channel to group them logically - i.e. only about 24 channels, but some of them in the hundreds, something I am sure not all together uncommon.
For display clarity, I have seen the following behaviour in other consoles: a toggle to switch which channels are displayed. In one, you could switch between all > active > manual > patched > ... (active being the channels that are either set from a cue/preset, or manually entered/altered, manual speaks for itsself).
Now, I am not suggesting that all this is necessary (while handy), but what would be great would probably be a simple patched filter, maybe on a hotkey? all <> patched? and all (as before) displaying the amount of channels as determined in the setup... that way, all channels that are not patched disappear, and you end up with a lean display that only shows channels that are actually involved in the show...
... just a thought, of course !
Channel display condensing
-
- Posts: 211
- Joined: Sat Jun 01, 2013 8:23 am
- Location: Adelaide, Australia
Channel display condensing
Cheers,
Freddy
Freddy
-
- Posts: 211
- Joined: Sat Jun 01, 2013 8:23 am
- Location: Adelaide, Australia
-
- Posts: 211
- Joined: Sat Jun 01, 2013 8:23 am
- Location: Adelaide, Australia
Actually, just thinking this through... when this option is ticked, what would be fantastic is that the OSC is interpreted differently, too... i.e. Let's say these channels are patched:
1, 4, 8 10.
If "only show channels that are patched" is checked, then it would be cool if somehow there was a different OSC address to receive/send levels, maybe "dynch"? That way, the gaps would be also closed in TouchOSC...
case 1: unpatched channels are SHOWN:
dynch >> ch
1 >> 1
2 >> 2
3 >> 3
4 >> 4
...
case 2: unpatched channels are HIDDEN:
dynch >> ch
1 >> 1
2 >> 4
3 >> 8
4 >> 10
Now, if TouchOSC always addresses the same address (dynch instead of ch), then it would work exactly the same way as the channel display of LXConsole.
The only other thing that would be handy (from my TouchOSC ipad remote point of view), would be to also send the ch number that is connected to each of the dynch at any one time (or, once again via applescript? a simple loop that sends [in order] all patched channels to an array of labels, similar to the submaster use routine you just wrote), for display purposes (my template displays the channel number in one label, and the channel use in another label).
This is obviously only one way how this could work, happy for any other suggestions .
1, 4, 8 10.
If "only show channels that are patched" is checked, then it would be cool if somehow there was a different OSC address to receive/send levels, maybe "dynch"? That way, the gaps would be also closed in TouchOSC...
case 1: unpatched channels are SHOWN:
dynch >> ch
1 >> 1
2 >> 2
3 >> 3
4 >> 4
...
case 2: unpatched channels are HIDDEN:
dynch >> ch
1 >> 1
2 >> 4
3 >> 8
4 >> 10
Now, if TouchOSC always addresses the same address (dynch instead of ch), then it would work exactly the same way as the channel display of LXConsole.
The only other thing that would be handy (from my TouchOSC ipad remote point of view), would be to also send the ch number that is connected to each of the dynch at any one time (or, once again via applescript? a simple loop that sends [in order] all patched channels to an array of labels, similar to the submaster use routine you just wrote), for display purposes (my template displays the channel number in one label, and the channel use in another label).
This is obviously only one way how this could work, happy for any other suggestions .
Cheers,
Freddy
Freddy
-
- Posts: 211
- Joined: Sat Jun 01, 2013 8:23 am
- Location: Adelaide, Australia
We could hear from others on this issue. However, my quick feeling is that channels are channels. If you want to assign them in sequential order, do that. If you want to leave whitespace (unpatched numbers) so the channels make logical sense, then do that.
I'm a great fan of the second option. I have a dance plot channel scheme that allows me to work in many different plots and still navigate by my "standard" channel assignments. I expect channel 81 to be the down left blue backlight. I'd be upset if I had to figure out that this is channel 69 (in order of only patched channels). The whole point of doing it the other way is that it makes sense...
But, I realize there's more than one way to do things. So, I'm happy to hear views on the issue.
Today, dimmer numbers are largely irrelevant to a designer, especially if they are handled automatically by software after they have been entered into the plot. Soon, channel numbers may suffer the same fate as software interfaces start to resemble magic sheets rather than command lines. You can already create a TouchOSC setup for controlling LXConsole that has channel numbers programmed to sliders in such a way that the user never has to deal with a channel number at all.
I'm a great fan of the second option. I have a dance plot channel scheme that allows me to work in many different plots and still navigate by my "standard" channel assignments. I expect channel 81 to be the down left blue backlight. I'd be upset if I had to figure out that this is channel 69 (in order of only patched channels). The whole point of doing it the other way is that it makes sense...
But, I realize there's more than one way to do things. So, I'm happy to hear views on the issue.
Today, dimmer numbers are largely irrelevant to a designer, especially if they are handled automatically by software after they have been entered into the plot. Soon, channel numbers may suffer the same fate as software interfaces start to resemble magic sheets rather than command lines. You can already create a TouchOSC setup for controlling LXConsole that has channel numbers programmed to sliders in such a way that the user never has to deal with a channel number at all.
-
- Posts: 211
- Joined: Sat Jun 01, 2013 8:23 am
- Location: Adelaide, Australia
Hi Claude, of course that makes sense... it was more following the logic of being able to hide unpatched channels, and carrying this benefit through logically to the control surface. It is of course achievable with the table of OSC assignments, but I just felt that if the computer's UI changes so radically with one checkbox, it would make sense that the Control Surface somehow follows .
But, of course, interested and open to suggestions...
But, of course, interested and open to suggestions...
Cheers,
Freddy
Freddy
-
- Posts: 211
- Joined: Sat Jun 01, 2013 8:23 am
- Location: Adelaide, Australia
Actually, I just realized, I could totally do this myself, provided a few applescript hooks would be accessible:
1. A Boolean (could be Read Only, or ideally Read/Write, so that maybe the script could actually triggering the toggling between the views...) that contains the state of the Menu option "View" > "Show Only Patched Channels
2. A noun "PatchList"? Or maybe individual "Channels"? with one property Channel Number, and one property that shows whether or not the channels has been patched (and maybe, too what?), maybe just Read Only.
3. A noun "OSCTable", where you can Read/Write the individual rows/entries...
That way, I am sure there is also other benefits for the keen scripters out there ...
But I don't know if it is easier to build in script hooks, or makes just as much work...?
Cheers,
Freddy
1. A Boolean (could be Read Only, or ideally Read/Write, so that maybe the script could actually triggering the toggling between the views...) that contains the state of the Menu option "View" > "Show Only Patched Channels
2. A noun "PatchList"? Or maybe individual "Channels"? with one property Channel Number, and one property that shows whether or not the channels has been patched (and maybe, too what?), maybe just Read Only.
3. A noun "OSCTable", where you can Read/Write the individual rows/entries...
That way, I am sure there is also other benefits for the keen scripters out there ...
But I don't know if it is easier to build in script hooks, or makes just as much work...?
Cheers,
Freddy
Cheers,
Freddy
Freddy