DrivenByMoss: Bitwig extension for many hardware controllers (version 26.6.1)

[mevla]

Hi. Is it possible to assign single pads on the Launchpad Mini as on/off switches instead of fader values ? If not, would it be possible with a rather old Launchpad Mini (the one with round pads) and the Flexi script, while at the same time the most recent Launchpad Mini is used with the most recent DrivenByMoss script ?

[moss]

Hi Jürgen,
here my "OSC Script Bug Report" (Track Navigation set to Flat, Bitwig 5.0, Drivenbymoss 20.3.0, OSC/PILOT interface), updated 6th of july

1. /track/selected/name does not give out Group-Track-Names. Instead, the last selected Non-Group-Track is shown.

2. /track/1-x/selected seems to have malfunctioning feedback, as soon as a group-track is existing in the project.

Example:
8 Audiotracks exist. Each AudioTrack is represented by
/track/selected/name and /track/1-8/selected on the OSC Interface.
When selecting Audiotracks, this properly shows in the OSC Interface.
But, when a grouptrack of any size is created, this newly created Grouptrack continues to be “selected” on the OSC Interface, even when switching focus to other Audiotracks within Bitwig.
And vice versa: when the Grouptrack isn’t selected in Bitwig/OSC, and i switch the selection from a Audiotrack to the Grouptrack, the Audiotrack continues to be “selected” on the OSC Interface.
I’m not sure, but this behavior might have something to do with /track/x/selected being able to Fold/Unfold the Grouptrack by pressing a Togglebutton (OSC OFF 0 and ON 1) twice. This is a really awesome function!, but maybe it’s “swallowing” the OSC OFF/ON message for showing on/off of the track-selection somehow. But that's just a guess.

3. Same Problem exists, when switching between selecting Audio and Miditracks. The last selected Audiotrack keeps showing as selected in the OSC interface, even when actually the Miditrack is now selected, and vice versa.
For Audio and Midi Clip-Slots (/track/x/clip/x/isSelected) the behavior is sometimes similar, but sometimes slightly different: instead of "is Selected" to change to the midi track, it stays with the Audiotrack - and the miditrack is falsely shown as not selected. It can also lead to several audio or midi clips being falsely shown as selected at the same time.

For the first three points above, i used a Bank page size equal to the number of my Tracks.

4. There is a buggy behavior when using a number for "Bank page size" which is higher than the number of existing Tracks. Result: Some Tracks never get fully loaded into the /track/x/name Textbox, when loading the Bitwig Liveset. They keep being empty, even when /refresh is used. Only when manually renaming the Track in Bitwig, the Textbox gets refreshed and shows the actual Trackname again - or when Restarting the OSC Script. Could be nice to have a /restart OSC script button!
But there are also problems which persist, even after restarting the OSC Script with OSC adresses like /selected. The problem gets worse the higher the difference between actual amount of Tracks and "Bank page size".
I know it says "must match your client template", but my client template has 24 Tracks and over 100 Scenes. Because i have a big Liveperformance Liveset (actually it has 300 Scenes the last time i put my songs into Ableton). I also encountered everything getting really slow (reaction speed of VU meters, selections, etc.) in both the Interface and bitwig with banksizes above 100 - and once OSC even crashed with a Java heap space error. (+ Bitwig crashed).
On my interface, i often times use dummy clips or support-samples which are in scenes far away from the first 30+ scenes - and i want to be able to press them immediately, without having to switch banks.

5. This is not a bug i think, but would love to know a solution: When using OSC Script to “select Clip”, for example /track/1/clip/20/select, Bitwigs Cliplauncher View (vertical and horizontal) doesn’t follow the selection! Is there any chance this might be changed to following the selection? Searching through the OSC commands, I haven't found any fast ways to scroll through Scenes or select specific scenes or clips, with Bitwigs view following.

Thank you for helping!

I am afraid there is not much I can do about these issues. OSC is a pretty heavy weight protocol due to the use of many strings. Sure, the length of the texts could be reduced to 1 character but this would kill the benefit of readbility.
Another reason for the issues could be that the client cannot keep up with processing the incoming messages.
For such a use-case it makes more sense to come up with your own optimized protocol.

[moss]

Script for Push 2 is awesome! A lot of features and more fun to play with Bitwig now.
I noticed some small issues.
Tempo knob lags a lot. It feels like there is some latency between twisting the knob and tempo change.

I can reproduce that as well. Please report to Bitwig support. It seems reflecting the value back to the API is somehow slow. Which is not the case with e.g. transport change.

Also it is very difficult to use the browser with push 2. For example when i twist "tags" knobs it jumps between tags like crazy

Hmm, looks fine to me. Is it too fast with all knobs? Could also be a hardware calibration issue.

[moss]

Hello. Is it possible with the Launchpad to assign pads on a per-pad basis and not as faders ? Like the keyboard and drum modes are doing, but user defined ?

Sorry, no.

[moss]

Hi Jürgen,

In Bitwig 5 the Project and Track Remotes are currently not accessable with the original Akai APC40, am I right?
Is this because there is nu clear UI button for this? I think the Akai APC40 mkII uses a User button the OG Akai APC40 does not have?

Yes and Yes.

Wouldn't it be an idea to user the Shift + <- & Shift + -> in the "Device Control" section so that once the most left device in a track is reached, the next Shift + <- press would go into Track Remote parameters, and one press more would go into Project Remote parameters, thus following what's happening on screen? Wouldn't that be a logical UX?

In theory yes, but that is would be difficult to detect.
But I am open to other suggestions

I would very much like to have access to these new Bitwig 5 features (Track & Project Remotes) with my beloved APC40 OG.

If you click on project or track remote controls in Bitwig, you can control them from the APC with the device knobs.

[moss]

Hey, I'm trying to add some scales... well, a lot of scales, maybe... heh.

I've found where in the git to put the scales but, uh, not really sure what to do from here to compile to a bwextension? im a scrub... I'm trying to add the missing 7 note scales (not all modes) and then the bebop scales.

i have no idea what to do with maven or git haha...

I am afraid I cannot give support this. But if you want to dive in, see my API programming tutorials on my Youtube channel, especially the one about Java development.

[moss]

would it be possible with a rather old Launchpad Mini (the one with round pads) and the Flexi script, while at the same time the most recent Launchpad Mini is used with the most recent DrivenByMoss script ?

Yes, you can do that.

[nowiamone]

Hi Jürgen,
here my "OSC Script Bug Report" (Track Navigation set to Flat, Bitwig 5.0, Drivenbymoss 20.3.0, OSC/PILOT interface), updated 6th of july

1. /track/selected/name does not give out Group-Track-Names. Instead, the last selected Non-Group-Track is shown.

2. /track/1-x/selected seems to have malfunctioning feedback, as soon as a group-track is existing in the project.

Example:
8 Audiotracks exist. Each AudioTrack is represented by
/track/selected/name and /track/1-8/selected on the OSC Interface.
When selecting Audiotracks, this properly shows in the OSC Interface.
But, when a grouptrack of any size is created, this newly created Grouptrack continues to be “selected” on the OSC Interface, even when switching focus to other Audiotracks within Bitwig.
And vice versa: when the Grouptrack isn’t selected in Bitwig/OSC, and i switch the selection from a Audiotrack to the Grouptrack, the Audiotrack continues to be “selected” on the OSC Interface.
I’m not sure, but this behavior might have something to do with /track/x/selected being able to Fold/Unfold the Grouptrack by pressing a Togglebutton (OSC OFF 0 and ON 1) twice. This is a really awesome function!, but maybe it’s “swallowing” the OSC OFF/ON message for showing on/off of the track-selection somehow. But that's just a guess.

3. Same Problem exists, when switching between selecting Audio and Miditracks. The last selected Audiotrack keeps showing as selected in the OSC interface, even when actually the Miditrack is now selected, and vice versa.
For Audio and Midi Clip-Slots (/track/x/clip/x/isSelected) the behavior is sometimes similar, but sometimes slightly different: instead of "is Selected" to change to the midi track, it stays with the Audiotrack - and the miditrack is falsely shown as not selected. It can also lead to several audio or midi clips being falsely shown as selected at the same time.

Thank you for helping!

I am afraid there is not much I can do about these issues. OSC is a pretty heavy weight protocol due to the use of many strings. Sure, the length of the texts could be reduced to 1 character but this would kill the benefit of readbility.
Another reason for the issues could be that the client cannot keep up with processing the incoming messages.
For such a use-case it makes more sense to come up with your own optimized protocol.

Thanks for looking into this! I'll leave the problems with the huge bank size for now,
I'm sadly not good with programming, even though i greatly admire your API tutorials on youtube, i feel i m a bit too dumb for making my own huge OSC script.
But concerning the first 3 points (bugs), I'm sorry to ask again, because they're refering to "normal" use case, happening even with Projects with only 8 Tracks. (and a small Bank Size number in OSC settings!)

I try to shorten my bugreport :
- When switching from Audio to Midi Track with /track/3/selected, the Audio Track still is shown as selected in the OSC interface, even though /track/2/selected should get an 0 value to turn off. Even the /track/2/recarm is affected by this 'falsely showing ON' bug, and track/x/clip/x/isSelected, too.
- Aside from the Audio/MidiTrack switching, there's another situation for the bug to appear: When switching from a Grouptrack to its childTracks (or vice versa), the Grouptrack still is shown as selected, and keeps showing as selected, even when moving to completely other tracks outside of the group.

Thanks alot for looking at it

[moss]

Hi Jürgen,
here my "OSC Script Bug Report" (Track Navigation set to Flat, Bitwig 5.0, Drivenbymoss 20.3.0, OSC/PILOT interface), updated 6th of july

1. /track/selected/name does not give out Group-Track-Names. Instead, the last selected Non-Group-Track is shown.

2. /track/1-x/selected seems to have malfunctioning feedback, as soon as a group-track is existing in the project.

Example:
8 Audiotracks exist. Each AudioTrack is represented by
/track/selected/name and /track/1-8/selected on the OSC Interface.
When selecting Audiotracks, this properly shows in the OSC Interface.
But, when a grouptrack of any size is created, this newly created Grouptrack continues to be “selected” on the OSC Interface, even when switching focus to other Audiotracks within Bitwig.
And vice versa: when the Grouptrack isn’t selected in Bitwig/OSC, and i switch the selection from a Audiotrack to the Grouptrack, the Audiotrack continues to be “selected” on the OSC Interface.
I’m not sure, but this behavior might have something to do with /track/x/selected being able to Fold/Unfold the Grouptrack by pressing a Togglebutton (OSC OFF 0 and ON 1) twice. This is a really awesome function!, but maybe it’s “swallowing” the OSC OFF/ON message for showing on/off of the track-selection somehow. But that's just a guess.

3. Same Problem exists, when switching between selecting Audio and Miditracks. The last selected Audiotrack keeps showing as selected in the OSC interface, even when actually the Miditrack is now selected, and vice versa.
For Audio and Midi Clip-Slots (/track/x/clip/x/isSelected) the behavior is sometimes similar, but sometimes slightly different: instead of "is Selected" to change to the midi track, it stays with the Audiotrack - and the miditrack is falsely shown as not selected. It can also lead to several audio or midi clips being falsely shown as selected at the same time.

Thank you for helping!

I am afraid there is not much I can do about these issues. OSC is a pretty heavy weight protocol due to the use of many strings. Sure, the length of the texts could be reduced to 1 character but this would kill the benefit of readbility.
Another reason for the issues could be that the client cannot keep up with processing the incoming messages.
For such a use-case it makes more sense to come up with your own optimized protocol.

Thanks for looking into this! I'll leave the problems with the huge bank size for now,
I'm sadly not good with programming, even though i greatly admire your API tutorials on youtube, i feel i m a bit too dumb for making my own huge OSC script.
But concerning the first 3 points (bugs), I'm sorry to ask again, because they're refering to "normal" use case, happening even with Projects with only 8 Tracks. (and a small Bank Size number in OSC settings!)

I try to shorten my bugreport :
- When switching from Audio to Midi Track with /track/3/selected, the Audio Track still is shown as selected in the OSC interface, even though /track/2/selected should get an 0 value to turn off. Even the /track/2/recarm is affected by this 'falsely showing ON' bug, and track/x/clip/x/isSelected, too.
- Aside from the Audio/MidiTrack switching, there's another situation for the bug to appear: When switching from a Grouptrack to its childTracks (or vice versa), the Grouptrack still is shown as selected, and keeps showing as selected, even when moving to completely other tracks outside of the group.

Thanks alot for looking at it

As I said I could not reproduce that. Tried both with flat and hierarchical track navigation. Are you going via a WiFi router or is this on the same machine?

[Skelmy]

Need to report a bug to you sir:

Novation Zero SL MK 2 Automap was working fine in previous version of Bitwig with previous Driven by Moss extension script (as it always has).
In Bitwig 5 with the new extension script doesn't work with Automap nor does the generic MIDI and MIDI learn on Bitwig end.
The Automap on the controller device says the plugin has no controlls and pressing the View botton on the controller device to pull up the Automap Server app on Windows 10 says it's empty as well.

I tested again earlier with previous version of Bitwig and previous version of Driven by Moss extension script and it's working fine, so it's not Windows 10 or anything like that.
Is there a possible change in the Bitwig 5 scripting change that breaks Automap?

Hope this helps get it fixed

[nowiamone]

As I said I could not reproduce that. Tried both with flat and hierarchical track navigation. Are you going via a WiFi router or is this on the same machine?

Sorry, i didn't understand that you already tried to reproduce it!
I m getting the bug on the same machine, but with OSCPILOT as program. Since i guess you tested with another program, i now tried to recreate it in Touch OSC.

Result:
- /track/x/recarm is working as expected in Touch OSC!
- /track/x/selected seems to be working as expected in Touch OSC too
So somehow this is only reproducable in OSCPILOT.
The malfunction is directly linked to the Tracks being Midi or Audio Tracks! This is really weird. I don't understand how OSCPILOT gets different behavior when switching from Midi to Audiotracks (and vice versa). Mystery of the universe...
edit: maybe my solution is only using hybrid tracks.

[nowiamone]

Feature wishes i have for the OSC Script:
- a "flush" tool to send 0 to every toggle button (my /track/x/clip/x/hasContent and others keep getting 'stuck', and even /refresh doesn't help)
EDIT: and/or a OSC/command for restarting the OSC Script! That would be awesome

- a way to make the OSC rectangle a "real" rectangle instead of a square
This would mean to have another setting for bank page size, refering to the scenes.
Then, the OSC controller rectangle could for example control 20 tracks but only 10 scenes at the same time

This is the current status of what i'm working on (thanks to you!), i'll share the basic template of it for others, when it's done.

interface 9 7 23.jpg

[moss]

Need to report a bug to you sir:

Novation Zero SL MK 2 Automap was working fine in previous version of Bitwig with previous Driven by Moss extension script (as it always has).
In Bitwig 5 with the new extension script doesn't work with Automap nor does the generic MIDI and MIDI learn on Bitwig end.
The Automap on the controller device says the plugin has no controlls and pressing the View botton on the controller device to pull up the Automap Server app on Windows 10 says it's empty as well.

I tested again earlier with previous version of Bitwig and previous version of Driven by Moss extension script and it's working fine, so it's not Windows 10 or anything like that.
Is there a possible change in the Bitwig 5 scripting change that breaks Automap?

Hope this helps get it fixed

Sorry, I have no idea. I am surprised that Automap is still working nowadays. How did you use it in combination with DrivenByMoss?

[ditzen]

Hi
Dead launchpad key problem here. (looks like i mapped the key to an instrument)

EDIT: problem is specific to a project. or it's settings. still finding out what.
2nd EDIT it was a single button mapped to an obscure knob.
-- no idea how to delete this reply yet. otherwise i would--

Firstly, many thanks for all the improvements made for the launchpad pro script with bitwig. There have been so many improvements. Great stuff thank you.

My setup. windows 10 laptop with bitwig 5. launchpad pro original. not sure if that makes it a mk1

My problem.
I have 1 dead key on the launchpad pro. (it was 2) now only the one above the solo button.
I am assuming it is not a hardware problem because works under the bitwig script for the launchpad pro. (that i don't like very much. yours is way better)

So far i have tried,
1. re-installing the launchpad pro firmware successfully from the novation website.
2. overwritten the latest extension pack from your site 20.3.0 for bitwig.

it was working briefly after i removed then added the controller again in bitwig's settings.

I am currently clueless and don't know where to look now. any pointers gratefully recieved

EDIT:
Just discovered this is specific to a given template or project. Swith to a different project and the the key is back
2nd EDIT it was a single button mapped to an obscure knob.

[Skelmy]

Need to report a bug to you sir:

Novation Zero SL MK 2 Automap was working fine in previous version of Bitwig with previous Driven by Moss extension script (as it always has).
In Bitwig 5 with the new extension script doesn't work with Automap nor does the generic MIDI and MIDI learn on Bitwig end.
The Automap on the controller device says the plugin has no controlls and pressing the View botton on the controller device to pull up the Automap Server app on Windows 10 says it's empty as well.

I tested again earlier with previous version of Bitwig and previous version of Driven by Moss extension script and it's working fine, so it's not Windows 10 or anything like that.
Is there a possible change in the Bitwig 5 scripting change that breaks Automap?

Hope this helps get it fixed

Sorry, I have no idea. I am surprised that Automap is still working nowadays. How did you use it in combination with DrivenByMoss?

With the SL MK 2 Driven by Moss extension script, the previous version and last version of Bitwig before 5 works fine.