3.10.0.5 beta / 3.11 alpha
4 posters
Page 1 of 10
Page 1 of 10 • 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
3.10.0.5 beta / 3.11 alpha
This is a beta release for version 3.10.0.5 and an alpha release for version 3.11.
The 3.10.0.5 beta has bug fixes for the (release) script bug and the Mackie button midi port bug. I have also updated to the latest versions of the frameworks and help libraries used. This shouldn't affect existing functionality (famous last words... ), but if you see any problem with existing buttons or dials, please report it. If no problems are found with existing buttons and dials, this will be released without the 3.11 alpha functions.
The 3.11 alpha version is not feature-complete. There are no changes to existing actions, but there is a new "Generic Midi" button intended to be an "all-inclusive" button that can use any Midi command in combination with any display type.
Currently, it can fully replace the CC button but not other buttons. The Note On/Off and Program Change buttons still have options not implemented for the Generic Midi button (e.g., articulation files and chords), and I am unsure if I should do that or if the Generic button is getting too complex that way. I'd love your thoughts on this,
The most reworked thing is the faders. The fader design is now completely "design-xml" based, and the "Mixer-like" and "My own" options from the CC button are dropped. I have also removed the option to colorize the handle and background as a mute indication and instead moved to a solution where you can display state icons. What are your thoughts about this?
The Latch functionality is not implemented yet. I initially thought of making a latch functionality that can take any combination of MIDI commands, but I don't know if that is overkill.
I intend to add Script functionality to the Generic Midi button, but before doing that, I need to add script commands to control faders and V-Pots. I will probably design the new script commands to be used even for dials, but that is for a later release.
I'd appreciate any comments you may have on this. Is this useful or overly complicated? What do you want to see added? What do you want to see changed?
Version 3.10.0.171 See later post
The 3.10.0.5 beta has bug fixes for the (release) script bug and the Mackie button midi port bug. I have also updated to the latest versions of the frameworks and help libraries used. This shouldn't affect existing functionality (famous last words... ), but if you see any problem with existing buttons or dials, please report it. If no problems are found with existing buttons and dials, this will be released without the 3.11 alpha functions.
The 3.11 alpha version is not feature-complete. There are no changes to existing actions, but there is a new "Generic Midi" button intended to be an "all-inclusive" button that can use any Midi command in combination with any display type.
Currently, it can fully replace the CC button but not other buttons. The Note On/Off and Program Change buttons still have options not implemented for the Generic Midi button (e.g., articulation files and chords), and I am unsure if I should do that or if the Generic button is getting too complex that way. I'd love your thoughts on this,
The most reworked thing is the faders. The fader design is now completely "design-xml" based, and the "Mixer-like" and "My own" options from the CC button are dropped. I have also removed the option to colorize the handle and background as a mute indication and instead moved to a solution where you can display state icons. What are your thoughts about this?
The Latch functionality is not implemented yet. I initially thought of making a latch functionality that can take any combination of MIDI commands, but I don't know if that is overkill.
I intend to add Script functionality to the Generic Midi button, but before doing that, I need to add script commands to control faders and V-Pots. I will probably design the new script commands to be used even for dials, but that is for a later release.
I'd appreciate any comments you may have on this. Is this useful or overly complicated? What do you want to see added? What do you want to see changed?
Last edited by Admin on Tue May 21, 2024 9:35 am; edited 1 time in total
Re: 3.10.0.5 beta / 3.11 alpha
Version 3.10.0.171 is the beta release for version 3.10.0.5 or the alpha release for version 3.11?
jordikt- Posts : 294
Join date : 2024-02-10
Re: 3.10.0.5 beta / 3.11 alpha
Both.
Everything except the Generic Midi button is the 3.10.0.5 beta that will be released (without the Generic Midi button) to fix the two bugs.
The Generic Midi button is the alpha part.
Everything except the Generic Midi button is the 3.10.0.5 beta that will be released (without the Generic Midi button) to fix the two bugs.
The Generic Midi button is the alpha part.
jordikt likes this post
Re: 3.10.0.5 beta / 3.11 alpha
Well noted. I will test it and report any feedback.
I have been thinking a wish for Mackie Fader dials: to show "Background_soloed" to the fader design (it would show the Solo state design like Mute state design).
If we could see mute and solo states in the background, we could avoid the left/right icons and use the whole space of the top for the track names.
A second wish is to add Mute/Solo states to Mackie Faders > Dial Rotate While Pressed Action: rotate left would toggle Mute and rotate right would toggle Solo.
I have been thinking a wish for Mackie Fader dials: to show "Background_soloed" to the fader design (it would show the Solo state design like Mute state design).
If we could see mute and solo states in the background, we could avoid the left/right icons and use the whole space of the top for the track names.
A second wish is to add Mute/Solo states to Mackie Faders > Dial Rotate While Pressed Action: rotate left would toggle Mute and rotate right would toggle Solo.
jordikt- Posts : 294
Join date : 2024-02-10
Re: 3.10.0.5 beta / 3.11 alpha
Bug: Scripts are not loading the images.
As example, the folowing script doesn’t change the default image of the script button:
[(init){image:%trevligaspel%/MackieLayouts/Buttons/Bypassed.png}]
I don't use Generic Midi Faders buttons, so I think I can't give you a valuable feedback regarding display state icons instead of background mute indicator, but it seems a good change. I also think it is good that the fader design is "design-xml" based.
The new Generic Midi button is a big change. I only use CC and NoteOn/Off. Both functions seems to work fine.
Great that script commands for V-Pots and Faders are planned for next release!
As example, the folowing script doesn’t change the default image of the script button:
[(init){image:%trevligaspel%/MackieLayouts/Buttons/Bypassed.png}]
I don't use Generic Midi Faders buttons, so I think I can't give you a valuable feedback regarding display state icons instead of background mute indicator, but it seems a good change. I also think it is good that the fader design is "design-xml" based.
The new Generic Midi button is a big change. I only use CC and NoteOn/Off. Both functions seems to work fine.
Great that script commands for V-Pots and Faders are planned for next release!
jordikt- Posts : 294
Join date : 2024-02-10
Re: 3.10.0.5 beta / 3.11 alpha
Thanks for the bug report.
When I upgraded the framework, I noted that the path to the Documents folder reported by macOS was changed. I had adjusted to that when using the %documents% variable but not when using the %trevligaspel% variable. This is fixed now.
Version 3.10.0.172
Regarding your "second wish" in previous post, you can add that functionality with some additions to the Mackie layout file.
When I upgraded the framework, I noted that the path to the Documents folder reported by macOS was changed. I had adjusted to that when using the %documents% variable but not when using the %trevligaspel% variable. This is fixed now.
Version 3.10.0.172
Regarding your "second wish" in previous post, you can add that functionality with some additions to the Mackie layout file.
- Create the folder "Trevliga Spel/MackieLayouts" if you don't have it.
- Copy the layout file you use from the corresponding folder in the plugin folder.
- At the end of the file, where there are a number of <Dial> entries, add a new entry like this:
- <Dial id="5" Name="Ch.1 Mute/Solo">
<Button direction="ccw" id="16" ></Button>
<Button direction="cw" id="8" ></Button>
</Dial> - The dial "id" should be the next in the sequence.
- For channels 2-8, add similar sections while increasing the three "id" attributes by one for each channel.
- The new options will be available under the "Daw Functions" section.
Last edited by Admin on Tue May 21, 2024 1:46 pm; edited 1 time in total
Re: 3.10.0.5 beta / 3.11 alpha
Shure this is another build?Admin wrote:Version 3.10.0.172
Joerg- Posts : 142
Join date : 2021-09-03
Re: 3.10.0.5 beta / 3.11 alpha
Confirmed that %trevligaspel% bug is fixed in version 3.10.0.172. All images are correclty loaded now in the script buttons.
Thanks A LOT for the code for Mute/solo the channels!! It works like a charm!!
Thanks A LOT for the code for Mute/solo the channels!! It works like a charm!!
jordikt- Posts : 294
Join date : 2024-02-10
Re: 3.10.0.5 beta / 3.11 alpha
Good morning,
Regarding the "script commands for control faders and V-Pots", will it enable to customize the title with variables ?
For example i would love to be able to :
This is my most wanted functionalitiy and the reason for it is quite obvious when integrating with a daw.
As we have only 4 dials it needs to be dynamically managed depending on track or device selection. It is similar to value display options provided by mackie controls (which I don't use).
Thanks for your support
Regarding the "script commands for control faders and V-Pots", will it enable to customize the title with variables ?
For example i would love to be able to :
- Receive a sysex message and store the variable content in a text variable
- Display this variable as the vpot or fader title
This is my most wanted functionalitiy and the reason for it is quite obvious when integrating with a daw.
As we have only 4 dials it needs to be dynamically managed depending on track or device selection. It is similar to value display options provided by mackie controls (which I don't use).
Thanks for your support
thx538- Posts : 130
Join date : 2023-10-23
Re: 3.10.0.5 beta / 3.11 alpha
My intention is to have "everything" controllable from the script.
- The fader/vpot position
- The text
- Icons (for the fader). At least on/off, but possibly also icon path.
- VU level (for the fader)
jordikt likes this post
Re: 3.10.0.5 beta / 3.11 alpha
Excellent !
I'll be happy to test when its available.
I'll be happy to test when its available.
thx538- Posts : 130
Join date : 2023-10-23
Re: 3.10.0.5 beta / 3.11 alpha
btw ... as far as I remember it's not feasible but maybe things have changed, so I wanted to check the 2nd and 3rd items on my wishlist :
Have a nice day.
- have an event to detect when the Streamdeck is plugged or unplugged
- have an action to change page programmatically.
Have a nice day.
thx538- Posts : 130
Join date : 2023-10-23
Re: 3.10.0.5 beta / 3.11 alpha
thx538 wrote:For example i would love to be able to :
- Receive a sysex message and store the variable content in a text variable
- Display this variable as the vpot or fader title
@thx538 I would also like to have this feature for displaying whole track names
Do you know how to receive track names in sysex from cubase or live? Could you share it in the forum?
jordikt- Posts : 294
Join date : 2024-02-10
Re: 3.10.0.5 beta / 3.11 alpha
thx538 wrote:
- have an event to detect when the Streamdeck is plugged or unplugged
- have an action to change page programmatically.
The first item is technically possible, but what is the use case for it?
The second item is not possible; plugins are not allowed to do that.
Re: 3.10.0.5 beta / 3.11 alpha
Hi Gunnar,
do you have a documentation on how to use the VU Meter of the new Generic Midi Button?
thx
Joerg
do you have a documentation on how to use the VU Meter of the new Generic Midi Button?
thx
Joerg
Joerg- Posts : 142
Join date : 2021-09-03
Re: 3.10.0.5 beta / 3.11 alpha
I'm sorry, but I haven't looked at the documentation yet. Things may change, so I wait to prepare the documentation until it's finished.
There is a section for the VU meter. Just select the control of your choice for the VU level. Let's say you configure the fader to control CC1 and the VU to be controlled by CC2. Received Midi commands for CC1 will control the fader position, while received Midi commands for CC2 will control the VU level.
There is a section for the VU meter. Just select the control of your choice for the VU level. Let's say you configure the fader to control CC1 and the VU to be controlled by CC2. Received Midi commands for CC1 will control the fader position, while received Midi commands for CC2 will control the VU level.
Re: 3.10.0.5 beta / 3.11 alpha
Scripting is implemented for the faders and vpots only (so far). The principle is this:
(press) and (release) events are NOT sent to the script. Instead, a button press moves the fader/vpot, and the script receives a (fader)/(vpot) event with the current fader/vpot value.
New events:
(fader:_value_)
(vpot:_value_)
New actions:
{value:_value_} sets the fader/vpot value.
{vu:_value_} sets the VU value (for faders).
{icon:_path_} sets the path for the state icon (for faders). To hide the icon, set {icon:#none#}
New reference variable:
@e_fadervalue keeps the current value of the fader, which is available in commands triggered by a (fader) event.
@e_vpotvalue keeps the current value of the vpot, which is available in commands triggered by a (vpot) event.
Contrary to non-scripted buttons, the plugin cannot automatically detect if two adjacent buttons should cooperate to control the same thing; instead, you must define if the button role is single, lower or upper.
When configuring two fader buttons to cooperate, both buttons should have the same script commands for the fader and VU settings. Each button runs its own script, and if the fader/VU commands differ, the result would be very confusing. The icon commands and the fader texts can (and probably should) differ between the two scripts since each button has its own icon and text.
When configuring two vpot buttons to cooperate, the script must be assigned to the lower button; it will apply to both buttons.
If (text) actions are used in the scripts, the "Value display" dropdown must be set to "Controlled by script" to display the script texts.
Two simple example scripts:
Upper fader button:
[(cc:1,0,*){value:#@e_ccvalue#}]
[(fader:*){cc:1,0,#@e_fadervalue#}]
[(cc:1,1,*){vu:#@e_ccvalue#}]
[(cc:1,0,127){icon:%trevligaspel%\icons\ACoolIcon.png}]
[(cc:1,0,<126<){icon:#none#}]
Lower fader button:
[(cc:1,0,*){value:#@e_ccvalue#}{text:#@e_ccvalue#}]
[(fader:*){cc:1,0,#@e_fadervalue#}]
[(cc:1,1,*){vu:#@e_ccvalue#}]
[(cc:1,0,0){icon:%trevligaspel%\icons\AnotherCoolIcon.png}]
[(cc:1,0,>1>){icon:#none#}]
The scripting logic is complex, especially with cooperating buttons; I'd be surprised if no bugs are found. Please report if you find anything wrong with scripting in general. I had to change the scripting engine to handle the new events and actions, and even though I took care not to change existing logic, it has happened - in very rare situations - that I have made minor (very minor) mistakes.
Version 3.10.0.230
(press) and (release) events are NOT sent to the script. Instead, a button press moves the fader/vpot, and the script receives a (fader)/(vpot) event with the current fader/vpot value.
New events:
(fader:_value_)
(vpot:_value_)
New actions:
{value:_value_} sets the fader/vpot value.
{vu:_value_} sets the VU value (for faders).
{icon:_path_} sets the path for the state icon (for faders). To hide the icon, set {icon:#none#}
New reference variable:
@e_fadervalue keeps the current value of the fader, which is available in commands triggered by a (fader) event.
@e_vpotvalue keeps the current value of the vpot, which is available in commands triggered by a (vpot) event.
Contrary to non-scripted buttons, the plugin cannot automatically detect if two adjacent buttons should cooperate to control the same thing; instead, you must define if the button role is single, lower or upper.
When configuring two fader buttons to cooperate, both buttons should have the same script commands for the fader and VU settings. Each button runs its own script, and if the fader/VU commands differ, the result would be very confusing. The icon commands and the fader texts can (and probably should) differ between the two scripts since each button has its own icon and text.
When configuring two vpot buttons to cooperate, the script must be assigned to the lower button; it will apply to both buttons.
If (text) actions are used in the scripts, the "Value display" dropdown must be set to "Controlled by script" to display the script texts.
Two simple example scripts:
Upper fader button:
[(cc:1,0,*){value:#@e_ccvalue#}]
[(fader:*){cc:1,0,#@e_fadervalue#}]
[(cc:1,1,*){vu:#@e_ccvalue#}]
[(cc:1,0,127){icon:%trevligaspel%\icons\ACoolIcon.png}]
[(cc:1,0,<126<){icon:#none#}]
Lower fader button:
[(cc:1,0,*){value:#@e_ccvalue#}{text:#@e_ccvalue#}]
[(fader:*){cc:1,0,#@e_fadervalue#}]
[(cc:1,1,*){vu:#@e_ccvalue#}]
[(cc:1,0,0){icon:%trevligaspel%\icons\AnotherCoolIcon.png}]
[(cc:1,0,>1>){icon:#none#}]
The scripting logic is complex, especially with cooperating buttons; I'd be surprised if no bugs are found. Please report if you find anything wrong with scripting in general. I had to change the scripting engine to handle the new events and actions, and even though I took care not to change existing logic, it has happened - in very rare situations - that I have made minor (very minor) mistakes.
Version 3.10.0.230
Re: 3.10.0.5 beta / 3.11 alpha
I have done this Scripted V-Pot:
[(cc:1,39,*){value:#@e_ccvalue#}{text:#@e_ccvalue#}]
[(vpot:*){cc:1,39,#@e_vpotvalue#}]
Everything works fine, except the direction arrows. Steps to reproduce the bug:
- Set direction to both ways
- Check Show direction on knob and/or on background
- The button always shows the left direction. The right arrow is never shown.
There is a visual bug in the Generic Midi button>V-Pot. The button sends and receives values, but the image is always frozen. If you change the page and go back to the button, the button has updated the value, the ring, the arrows, etc, but if you press it again the image is frozen again.
Assigning a specific value to the vpot command (or even removing it) doesn't cause any error. As example the following lines gives the same result:
[(vpot:*){text:#@e_vpotvalue#}]
[(vpot:12){text:#@e_vpotvalue#}]
[(vpot){text:#@e_vpotvalue#}]
Hope it helps!
Thanks for this update!
[(cc:1,39,*){value:#@e_ccvalue#}{text:#@e_ccvalue#}]
[(vpot:*){cc:1,39,#@e_vpotvalue#}]
Everything works fine, except the direction arrows. Steps to reproduce the bug:
- Set direction to both ways
- Check Show direction on knob and/or on background
- The button always shows the left direction. The right arrow is never shown.
There is a visual bug in the Generic Midi button>V-Pot. The button sends and receives values, but the image is always frozen. If you change the page and go back to the button, the button has updated the value, the ring, the arrows, etc, but if you press it again the image is frozen again.
Assigning a specific value to the vpot command (or even removing it) doesn't cause any error. As example the following lines gives the same result:
[(vpot:*){text:#@e_vpotvalue#}]
[(vpot:12){text:#@e_vpotvalue#}]
[(vpot){text:#@e_vpotvalue#}]
Hope it helps!
Thanks for this update!
jordikt- Posts : 294
Join date : 2024-02-10
Re: 3.10.0.5 beta / 3.11 alpha
Adding a custom variable event to the vpot event is not working as expected.
As example, the following code:
[(cc:1,39,*)(@shift:1){value:#@e_ccvalue#}{text:#@e_ccvalue#}]
[(vpot:*)(@shift:1){cc:1,39,#@e_vpotvalue#}]
Steps:
- Set @shift to 0
- The value of the vpot is i.e. 100
- Press the vpot button
- The ring of the vpot increase/decrease, but the cc value remains at 100 (and no other cc values are sent)
- Set @shift to 1
- The ring returns to the value of 100
So the only issue is a visual bug: the vpot ring increases/decreases while the button is pressed even when a multi-event condition is not true.
Setting the custom variable at the beginning doesn't fix the ring behaviour:
[(@shift:1)(vpot:*){cc:1,39,#@e_vpotvalue#}]
As example, the following code:
[(cc:1,39,*)(@shift:1){value:#@e_ccvalue#}{text:#@e_ccvalue#}]
[(vpot:*)(@shift:1){cc:1,39,#@e_vpotvalue#}]
Steps:
- Set @shift to 0
- The value of the vpot is i.e. 100
- Press the vpot button
- The ring of the vpot increase/decrease, but the cc value remains at 100 (and no other cc values are sent)
- Set @shift to 1
- The ring returns to the value of 100
So the only issue is a visual bug: the vpot ring increases/decreases while the button is pressed even when a multi-event condition is not true.
Setting the custom variable at the beginning doesn't fix the ring behaviour:
[(@shift:1)(vpot:*){cc:1,39,#@e_vpotvalue#}]
jordikt- Posts : 294
Join date : 2024-02-10
Re: 3.10.0.5 beta / 3.11 alpha
Maybe I don't know how to configure it correctly, but a double handle is showed in the combo faders.
The handle is duplicated in the two buttons in Generic Midi>Faders and Generic Midi>Scripted Faders.
The handle is showed correctly in the CC/NRPN button.
Next image shows two scripted fader buttons (lower and upper) with duplicated handle:
Here the same problem with Generic Midi>Fader:
Scripted fader has the same issue than scripted vpot: a multievent configuration with a custom variable is not working as expected.
Same steps:
- Set @shift to 0
- The value of the fader is i.e. 100
- Press the scripted fader button
- The handle of the fader moves, but the cc value remains at 100 (no other cc value is sent)
- Set @shift to 1
- The handle returns to the position of 100
Icons are shown correctly. I haven't test the VU because I don't know how to set the channel and cc for receiving the VU. I would appreciate if you can explain how to receive the VU. Thanks.
The handle is duplicated in the two buttons in Generic Midi>Faders and Generic Midi>Scripted Faders.
The handle is showed correctly in the CC/NRPN button.
Next image shows two scripted fader buttons (lower and upper) with duplicated handle:
Here the same problem with Generic Midi>Fader:
Scripted fader has the same issue than scripted vpot: a multievent configuration with a custom variable is not working as expected.
Same steps:
- Set @shift to 0
- The value of the fader is i.e. 100
- Press the scripted fader button
- The handle of the fader moves, but the cc value remains at 100 (no other cc value is sent)
- Set @shift to 1
- The handle returns to the position of 100
Icons are shown correctly. I haven't test the VU because I don't know how to set the channel and cc for receiving the VU. I would appreciate if you can explain how to receive the VU. Thanks.
jordikt- Posts : 294
Join date : 2024-02-10
Re: 3.10.0.5 beta / 3.11 alpha
This is what I use in the Live script to send the sysex from the selected track.jordikt wrote:thx538 wrote:For example i would love to be able to :
- Receive a sysex message and store the variable content in a text variable
- Display this variable as the vpot or fader title
@thx538 I would also like to have this feature for displaying whole track names
Do you know how to receive track names in sysex from cubase or live? Could you share it in the forum?
- Code:
def on_selected_track_changed(self):
""" Called by the control surface when a track is selected, to be overridden """
track = self.song().view.selected_track
tnum = list(self.song().tracks).index(track)
self.track_listener(tnum, 'SELECTED')
""" Format and send sysex with track name"""
self.send_track_name(tnum, 0)
""" Format and send sysex with track name"""
def send_track_name(self, tnum, ttype):
# ttype : 0 = Selected track, 1 = Session box Track
tname = self.song().tracks[tnum].name.ljust(8)
# Send SYSEX With prefix 110=6E, , ord = ASCII conversion
self.canonical_parent._send_midi((240,110, ttype, tnum, ord(tname[0:1]),ord(tname[1:2]),ord(tname[2:3]),ord(tname[3:4]),ord(tname[4:5]),ord(tname[5:6]),ord(tname[6:7]),ord(tname[7:8]),247))
NB:
- This code is entered as part of a user action script within ClyphX Pro, but it could easily changed to run from inside a custom Ableton live script.
- When I implemented it, string variables and sysex processing were not available in the midi plugin, so I have an ugly transformation done in between with Bome midi translator.
- I will make some changes to benefit from string variables and sysex as script event and will post the code if you are interested.
thx538- Posts : 130
Join date : 2023-10-23
Re: 3.10.0.5 beta / 3.11 alpha
Admin wrote:thx538 wrote:
- have an event to detect when the Streamdeck is plugged or unplugged
- have an action to change page programmatically.
The first item is technically possible, but what is the use case for it?
The second item is not possible; plugins are not allowed to do that.
I have custom scripts portions in Ableton live to send Sysex with:
- Selected track name (See my above post)
- Session box (aka red box) tracks names (x4) to use the dials as mixer controls (Vol., Pan, Sends A & B)
- Parameters names (macro controls, x16) for the currently selected device in Live.
What I would like to do with the plugged/unplugged events is to activate/deactivate those scripts portions in Live and also the corresponding sysex processing in in Bome Midi Translator, so as to avoid unnecessary midi chatting for performance reason.
Thanks for your support and eventually let us know when it's implemented.
Have a nice day.
thx538- Posts : 130
Join date : 2023-10-23
Re: 3.10.0.5 beta / 3.11 alpha
Oh, man! I was elated when I got dual scripted vertical faders to work, but obviously, I missed some other minor details.
I can confirm the stuck Vpot.
I cannot reproduce the horizontal faders (scripted or not) with double handles.
I haven't tested the other issues yet.
The VU meter seems to cause some confusion.
For scripted faders, you trigger on the appropriate event and use the {vu:} action to set the VU level, e.g.:
[(cc:1,0,*){vu:#@e_ccvalue#}]
There is no on/off switch for the scripted VU meter. If the value is not set or set to 0, it is not shown.
I can confirm the stuck Vpot.
I cannot reproduce the horizontal faders (scripted or not) with double handles.
I haven't tested the other issues yet.
The VU meter seems to cause some confusion.
- For non-scripted faders, the editor has a section "VU meter," where you can enable the VU meter and set the channel and control (if applicable) it should respond to.
- If set to CC or something else with a value, it will listen for that CC and use the received value as the VU level.
- If set to Pitchbend or something else without a value, it
willshould listen on the channel and use the received command as the VU level. This seems to fail.
[(cc:1,0,*){vu:#@e_ccvalue#}]
There is no on/off switch for the scripted VU meter. If the value is not set or set to 0, it is not shown.
Re: 3.10.0.5 beta / 3.11 alpha
Hi @thx538
Thanks for your reply.
I will appreciate if you can share the code if you improve it, thanks.
I use Bome Midi Translator Pro too.
If you are a MacOS user, I can send you applescript code to detect any device connected to the computer by USB and/or thunderbold.
Thanks for your reply.
I will appreciate if you can share the code if you improve it, thanks.
I use Bome Midi Translator Pro too.
If you are a MacOS user, I can send you applescript code to detect any device connected to the computer by USB and/or thunderbold.
jordikt- Posts : 294
Join date : 2024-02-10
Page 1 of 10 • 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
Page 1 of 10
Permissions in this forum:
You cannot reply to topics in this forum