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

[nowiamone]

Will add it to the wishlist.

[nowiamone]

i found something, which might be unwanted behavior. It's a very minor thing, but nevertheless i'll share it with you:

When using /automationWriteMode (latch touch write),
not only the automation mode changes, but also /autowrite is turned on, which is the Arrangement Automation Write.
This could be unwanted behavior, because the Latch Touch Write setting are also good for the Cliplauncher Automation Write - in which case the Arrangement Automation Write is not needed/wanted. Just a very minor thing

[moss]

i found something, which might be unwanted behavior. It's a very minor thing, but nevertheless i'll share it with you:

When using /automationWriteMode (latch touch write),
not only the automation mode changes, but also /autowrite is turned on, which is the Arrangement Automation Write.
This could be unwanted behavior, because the Latch Touch Write setting are also good for the Cliplauncher Automation Write - in which case the Arrangement Automation Write is not needed/wanted. Just a very minor thing

I agree.

[mevla]

Hello. I'm using the Launchpad Mini to control a performance parameter device page for the polygrid regarding ratios. The performance controls works fine, slowly incrementing either sides of the ratios, but the Launchpad pads are jumping by large numbers. Is it possible to specify a range, like 8 pads would squarely be limited to 1 to 8. no other values allowed ?

[tdmusic]

I have no idea so far. But I could not spot the usual script in the Ableton update. Therefore, it is possible that it might be completely locked down.

I don’t have any context here, just came across this on another forum, but are you looking for the Ableton Python scripts?

If so they now reside somewhere in Helpers/Push3.app in the Ableton bundle (on Mac), not at my computer so I can’t check the exact path but the usual pyc files are in there somewhere (under the name Push2). It looks like just an evolution of the old code, but right now Push2 still uses the old scripts - but there are “if push 3” checks in the new code so I assume they plan to migrate them both to use this separate Python codebase in time.

If this isn’t what you were talking about then sorry haha

[carlca]

Hi Moss!

I have a Bitwig Extension API project which started off life written in Java and built in Maven, and it worked, as far as it went.

I've just migrated the project to Scala and am trying to use sbt as the build engine. Using the sbt-assembly plugin and a tweak to my build.sbt, I have managed to build a .jar file which has my code PLUS the dependencies but MINUS the Bitwig code, so structurally it is roughly the same as it was before.

The problem is that Bitwig doesn't recognise the new .bwextension. This is what I get if I launch Bitwig from the command line...

Code: Select all

[2023-06-01 12:28:28.315 extension-registry error] Error scanning extension file MidiMix.bwextension:
	java.io.IOException: No extensions found in /Users/carlcaulkett/Documents/Bitwig Studio/Extensions/MidiMix.bwextension
	at oLk.hl(SourceFile:126)
	at ODP.dRm(SourceFile:644)
	at ODP.U3Y(SourceFile:626)
	at Xuy.visitFile(SourceFile:595)
	at URj.U3Y(SourceFile:93)
	at URj.visitFile(SourceFile:18)
	at java.base/java.nio.file.Files.walkFileTree(Unknown Source)
	at dNk.U3Y(SourceFile:632)
	at dNk.hl(SourceFile:614)
	at EbU.hl(SourceFile:906)
	at ODP.hgA(SourceFile:585)
	at ODP.dRm(SourceFile:220)
	at oMS.run(SourceFile:196)
	at AYU.run(SourceFile:307)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)

My question is: Exactly what is Bitwig looking for when it tries to load in an extension? Is it looking at the validity of my MidiMixExtension class and my MidiMixExtensionDefinition class? I'm pretty sure that the structure of the two classes was correct, and that the Extension class had all of the overrides in place for things like the Hardware Vendor and Product. Is there some piece of metadata that is missing. I'm sure it's something straightforward, but I just can't see it!

[SteveElbows]

I have no idea so far. But I could not spot the usual script in the Ableton update. Therefore, it is possible that it might be completely locked down.

I don’t have any context here, just came across this on another forum, but are you looking for the Ableton Python scripts?

If so they now reside somewhere in Helpers/Push3.app in the Ableton bundle (on Mac), not at my computer so I can’t check the exact path but the usual pyc files are in there somewhere (under the name Push2). It looks like just an evolution of the old code, but right now Push2 still uses the old scripts - but there are “if push 3” checks in the new code so I assume they plan to migrate them both to use this separate Python codebase in time.

If this isn’t what you were talking about then sorry haha

I just came here to post much the same info.Inside that Push3 package on Mac its Contents/Resources/python/Push2/ which also includes files that imply Push 3 such as battery_component.pyc and wifi_setup.pyc

I have a Push 3 standalone (which I can obviously also run in controller mode) and a Mac if any initial proof of concept basic connection + writing to the screen testing is required.

[nowiamone]

After further OSC script experiences, my feature suggestions would be (sorry for asking for more):

- add another adress for VU Meters, which are "true output" VU Meters.
Right now the /track/x/vu always shows the VU Movement, even when the Track is muted (or when another Track is soloed).
A "true output" VU Meter would only show decibels which truly reach the listeners ear, really helps for maintaining a nice overview

- add VU Peak-Hold-Meter as String format (in db, just like /track/{1-8}/volumeStr), like Bitwig shows in the MIX-SHOW BIG METERS-View
- add VU Peak-Hold-Meter reset Button, counting for all Tracks (to be more easy)

- add FX tracks, with VU Meters, Volume, etc. (maybe i overlooked them?)

- By the way: any news from Bitwig about the "Clip-Playback-Progress" Feature request?
I think /clip_playback_progress would be really awesome, for anyone who is performing music live on a self made interface. Much more important than any of the above feature suggestions.
Edit: I think i forgot to send my mail to them about that topic, woops, sorry!! I will soon, but have a question:
i m uncertain about the technical side - how to tell Bitwig how the adress should work.
I guess the tricky part is the following: In OSC Interfaces (like my OSC/PILOT) the Widgets, like a horizontal Fader, which could visually show the Clip-Playback-Progress, need to be able to show all different types of clip-lengths correctly, from 1 bar length up to many bars length!
So i guess the values sent by /clip_playback_progress must be quite high-resolution, reaching from 0 to 1000 at least, so the Fader-Widgets can show the PlaybackProgress smoothly, independently from if the Clip length is 1 Bar or 50 bars. ?

- please add more user actions in the OSC script menu, if possible Would be really really great, because we see so many nice functions and yet have to decide to only choose 8 of them

Maybe a Bug :
- /track/{1-8}/send/{1-8}/activated seems to be read-only, if i see it correctly. The OSC widget receives the on/off state, but cannot send it to Bitwig, for whatever reason.

[moss]

I just came here to post much the same info.Inside that Push3 package on Mac its Contents/Resources/python/Push2/ which also includes files that imply Push 3 such as battery_component.pyc and wifi_setup.pyc

I have a Push 3 standalone (which I can obviously also run in controller mode) and a Mac if any initial proof of concept basic connection + writing to the screen testing is required.

Thanks for the info! Is the Push 3 showing up in the normal MIDI configuration in Ableton? I could'nt spot any "Push 3" entry in there.
If you can find out more about the interface, this would be great. Did you try to run DrivenByMoss with it?

[moss]

Hi Moss!

I have a Bitwig Extension API project which started off life written in Java and built in Maven, and it worked, as far as it went.

I've just migrated the project to Scala and am trying to use sbt as the build engine. Using the sbt-assembly plugin and a tweak to my build.sbt, I have managed to build a .jar file which has my code PLUS the dependencies but MINUS the Bitwig code, so structurally it is roughly the same as it was before.

The problem is that Bitwig doesn't recognise the new .bwextension. This is what I get if I launch Bitwig from the command line...

Code: Select all

[2023-06-01 12:28:28.315 extension-registry error] Error scanning extension file MidiMix.bwextension:
	java.io.IOException: No extensions found in /Users/carlcaulkett/Documents/Bitwig Studio/Extensions/MidiMix.bwextension
	at oLk.hl(SourceFile:126)
	at ODP.dRm(SourceFile:644)
	at ODP.U3Y(SourceFile:626)
	at Xuy.visitFile(SourceFile:595)
	at URj.U3Y(SourceFile:93)
	at URj.visitFile(SourceFile:18)
	at java.base/java.nio.file.Files.walkFileTree(Unknown Source)
	at dNk.U3Y(SourceFile:632)
	at dNk.hl(SourceFile:614)
	at EbU.hl(SourceFile:906)
	at ODP.hgA(SourceFile:585)
	at ODP.dRm(SourceFile:220)
	at oMS.run(SourceFile:196)
	at AYU.run(SourceFile:307)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)

My question is: Exactly what is Bitwig looking for when it tries to load in an extension? Is it looking at the validity of my MidiMixExtension class and my MidiMixExtensionDefinition class? I'm pretty sure that the structure of the two classes was correct, and that the Extension class had all of the overrides in place for things like the Hardware Vendor and Product. Is there some piece of metadata that is missing. I'm sure it's something straightforward, but I just can't see it!

I guess you are missing the services file (see my Youtube tutorials, sepcifially the one about Java development).
Please post such questions in a separate thread.

[moss]

- add another adress for VU Meters, which are "true output" VU Meters.
Right now the /track/x/vu always shows the VU Movement, even when the Track is muted (or when another Track is soloed).
A "true output" VU Meter would only show decibels which truly reach the listeners ear, really helps for maintaining a nice overview

- add VU Peak-Hold-Meter as String format (in db, just like /track/{1-8}/volumeStr), like Bitwig shows in the MIX-SHOW BIG METERS-View
- add VU Peak-Hold-Meter reset Button, counting for all Tracks (to be more easy)

The VU values are still back from v1. They need an overhaul first to make this possible.

- add FX tracks, with VU Meters, Volume, etc. (maybe i overlooked them?)

The OSC implementations follows pretty closely to what I did with the 1st Push. Which means there are two track banks: the normal one and the FX bank. There is a command to toggle between the 2.

- By the way: any news from Bitwig about the "Clip-Playback-Progress" Feature request?
I think /clip_playback_progress would be really awesome, for anyone who is performing music live on a self made interface. Much more important than any of the above feature suggestions.
Edit: I think i forgot to send my mail to them about that topic, woops, sorry!! I will soon, but have a question:
i m uncertain about the technical side - how to tell Bitwig how the adress should work.
I guess the tricky part is the following: In OSC Interfaces (like my OSC/PILOT) the Widgets, like a horizontal Fader, which could visually show the Clip-Playback-Progress, need to be able to show all different types of clip-lengths correctly, from 1 bar length up to many bars length!
So i guess the values sent by /clip_playback_progress must be quite high-resolution, reaching from 0 to 1000 at least, so the Fader-Widgets can show the PlaybackProgress smoothly, independently from if the Clip length is 1 Bar or 50 bars. ?

Didn't hear anything new about this.

- please add more user actions in the OSC script menu, if possible Would be really really great, because we see so many nice functions and yet have to decide to only choose 8 of them

I guess you mean user parameters?! They are also banked into pages and you can switch them. They will be replaced in the future by the project/track remote controls anyway.

Maybe a Bug :
- /track/{1-8}/send/{1-8}/activated seems to be read-only, if i see it correctly. The OSC widget receives the on/off state, but cannot send it to Bitwig, for whatever reason.

That is simply not yet implemented.

[nowiamone]

Hello,
what i mean by user actions is the /action/1-8 OSC adress
In the Bitwig Preferences-> Controllers -> OSC, there are 8 Slots to assign actions. Sadly, there are 21 categories to choose from, with 5 up to 50 different commands in each category. Although i m sure noone will ever need all of them, still, the restriction to 8 user actions feels quite limiting.
But i also have to add: thanks for making those /action commands available in general! Even the 8 already are of great value to me

Now i understand better: When the OSC implementation follows Push-Logic, then it's inevitable to run into limitations for me, because the "Logic" behind my OSC Interface is: never having to switch a view, in order to see more. I love seeing everything at once, which is possible on a 24 inch touchmonitor Hence my request for seeing Group-Track-Content without Toggling (without the necessity to enter the group) and seeing FX Tracks.
I m very glad though, that you made the option to increase bank size in general, this already helped me a lot to see all Tracks and Faders at once !

[moss]

Hello,
what i mean by user actions is the /action/1-8 OSC adress
In the Bitwig Preferences-> Controllers -> OSC, there are 8 Slots to assign actions. Sadly, there are 21 categories to choose from, with 5 up to 50 different commands in each category. Although i m sure noone will ever need all of them, still, the restriction to 8 user actions feels quite limiting.
But i also have to add: thanks for making those /action commands available in general! Even the 8 already are of great value to me

Ah, OK. That can be done.

[SteveElbows]

Thanks for the info! Is the Push 3 showing up in the normal MIDI configuration in Ableton? I could'nt spot any "Push 3" entry in there.

No, I think its probably connecting by other means, which might explain why the Python scripts were in a different location too.

If you can find out more about the interface, this would be great. Did you try to run DrivenByMoss with it?

DrivenByMoss does not auto-detect it in Bitwig, and when I set it up manually there is nothing listed in the USB dropdown. (just a device ID issue?)

Some initial info about my standalone Push 3's USB details when run in controller mode and connected to a modern Mac:

Different device ID, this one has advanced by a few digits compared to Push 2 and is 0x1969
Vendor ID 0x2982
Named Ableton Push 3 in Mac sysinfo.

MIDI port names on Mac:
Ableton Push 3 Live Port
Ableton Push 3 User Port
Ableton Push 3 External Port

Plenty of MIDI messages transmitted from the controls and pad surface, including note ons when touching touch-sensitive controls. The pads are transmitting the MPE form of MIDI.

[SteveElbows]

Good news.....

I dont know how to hack around with DrivenByMoss files so I did a test by hacking https://github.com/ffont/push2-python instead.

I changed the name of MIDI ports and the USB Device ID in their code, ran their example code that updates the display, and it worked, the Push 3 display updates and shows what is expected and encoders etc respond. So the Push 3 implementation for display etc is pretty much the same as the Push 2s and has not been locked down.