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

[AFranke]

Something different.

As I was testing out my controllers in Ableton Live I realized that if you navigate with them inside of Live they behave independently from each other. In Bitwig in contrast they always follow each other, which is very uncomfortable if you use more than one controller, but want them to do different jobs on different channels. I know, I can pin the controller to a specific track, but that is not the same. In Ableton, you can navigate the SLMK3 to Track 1-8 (it shows these tracks in the display and so on) and move the Push to e.g. to track 20-28 (it shows these tracks in the display and so on). If you now select track 25 on the Push it arms it and you can perform on track 25 on the push, while the SLMK3 stays where it is and is not affected, if I now want to perform track 6, which is in the viewpoint of the SLMK3, I only have to select track 6 on the SLMK3 and can perform there, the Push stays where it is. This behaviour is perfect for someone like me, who performs with more than one MIDI-Controller/-Keyboard. It would be a dream to be able to work so comfortably in Bitwig, but unfortunately in BWS the controllers always affect the others. Is this a problem with the controller script/extension, or is this a problem with Bitwigs controller API?

Regards Andreas

[moss]

No, it is no power issue. I also contacted Bitwig-Support on this. I had to send them the Bitwig log files so they can see there is no issue with the USB connection of the controllers. But I can see in the Controller Script Console that your extension first removes MIDIOUT2 and then immediately adds them again after that. This only happens with Controllers controlled DrivenByMoss, other controllers on the same USB-Hub and physical Port are unaffected. I also tested the Push and SLMK3 separated on different Hubs and different Ports (direct connection to the Motherboard), I tried two different (active of course) quality USB Hubs (around 100 € each) with 70 and 90 Watt power supplies. In addition to that, both controllers also had their dedicated power supplies attached, all the time. In the Controller Script Console, you can also see, that this happens with exclusively to the MIDIOUT2 connections, the MIDI-IN ports of the connection are NOT affected. This is why I come to the conclusion, that this problem has no relation to buggy hardware. I also ran the controllers for some days in Ableton Live and had no problems there, and as I said before, Bitwig support said that the connections of the controllers are stable, and there is no abortion of the connection from Bitwig Studios' view.

Hi Andreas, ein Fehler dazu ist auch in den Logfiles nicht zu sehen. Wie lange hat es gedauert, bis der Fehler auftrat? Das logfile geht von 20:36 bis 22:10? Bei welcher Aktion genau trat der Fehler auf und ist es jetzt vielleicht reproduzierbar?

And if you ask, no I can't force the problem to happen. It happens totally randomly.

Adding and removing ports and devices is totally handled by Bitwig and triggered by the OS. I have no control over this.
One thing to check: I noticed that "since some time" Bitwig does restart all controllers if there is a change on the USB network, e.g. when inserting or removing a USB stick.

[moss]

Something different.

As I was testing out my controllers in Ableton Live I realized that if you navigate with them inside of Live they behave independently from each other. In Bitwig in contrast they always follow each other, which is very uncomfortable if you use more than one controller, but want them to do different jobs on different channels. I know, I can pin the controller to a specific track, but that is not the same. In Ableton, you can navigate the SLMK3 to Track 1-8 (it shows these tracks in the display and so on) and move the Push to e.g. to track 20-28 (it shows these tracks in the display and so on). If you now select track 25 on the Push it arms it and you can perform on track 25 on the push, while the SLMK3 stays where it is and is not affected, if I now want to perform track 6, which is in the viewpoint of the SLMK3, I only have to select track 6 on the SLMK3 and can perform there, the Push stays where it is. This behaviour is perfect for someone like me, who performs with more than one MIDI-Controller/-Keyboard. It would be a dream to be able to work so comfortably in Bitwig, but unfortunately in BWS the controllers always affect the others. Is this a problem with the controller script/extension, or is this a problem with Bitwigs controller API?

Regards Andreas

In general, this is possible. But you have to decide on this before startup of the controller. On many controllers it does not make much sense, since you have no idea where you are in the project. Actually, you are the first one asking about this but I see the use-case.
I can add it to my wishlist but this will be very low priority.

[AFranke]

No, it is no power issue. I also contacted Bitwig-Support on this. I had to send them the Bitwig log files so they can see there is no issue with the USB connection of the controllers. But I can see in the Controller Script Console that your extension first removes MIDIOUT2 and then immediately adds them again after that. This only happens with Controllers controlled DrivenByMoss, other controllers on the same USB-Hub and physical Port are unaffected. I also tested the Push and SLMK3 separated on different Hubs and different Ports (direct connection to the Motherboard), I tried two different (active of course) quality USB Hubs (around 100 € each) with 70 and 90 Watt power supplies. In addition to that, both controllers also had their dedicated power supplies attached, all the time. In the Controller Script Console, you can also see, that this happens with exclusively to the MIDIOUT2 connections, the MIDI-IN ports of the connection are NOT affected. This is why I come to the conclusion, that this problem has no relation to buggy hardware. I also ran the controllers for some days in Ableton Live and had no problems there, and as I said before, Bitwig support said that the connections of the controllers are stable, and there is no abortion of the connection from Bitwig Studios' view.

Hi Andreas, ein Fehler dazu ist auch in den Logfiles nicht zu sehen. Wie lange hat es gedauert, bis der Fehler auftrat? Das logfile geht von 20:36 bis 22:10? Bei welcher Aktion genau trat der Fehler auf und ist es jetzt vielleicht reproduzierbar?

And if you ask, no I can't force the problem to happen. It happens totally randomly.

Adding and removing ports and devices is totally handled by Bitwig and triggered by the OS. I have no control over this.
One thing to check: I noticed that "since some time" Bitwig does restart all controllers if there is a change on the USB network, e.g. when inserting or removing a USB stick.

Ok, but that's not the case here. I don't have inserted or removed any USB device in this case. And it also does not happen to the other controllers I also have attached, which are not controlled by your extension by the way. It only happens to devices that are under the control of the DrivenByMoss extension.

Nonetheless, now I also added my old APC40, which was laying around here, to my setup. I connected it to another and different port on my computer. I will see what happens to this the next time the problem occurs.

Best regards
Andreas

[AFranke]

Something different.

As I was testing out my controllers in Ableton Live I realized that if you navigate with them inside of Live they behave independently from each other. In Bitwig in contrast they always follow each other, which is very uncomfortable if you use more than one controller, but want them to do different jobs on different channels. I know, I can pin the controller to a specific track, but that is not the same. In Ableton, you can navigate the SLMK3 to Track 1-8 (it shows these tracks in the display and so on) and move the Push to e.g. to track 20-28 (it shows these tracks in the display and so on). If you now select track 25 on the Push it arms it and you can perform on track 25 on the push, while the SLMK3 stays where it is and is not affected, if I now want to perform track 6, which is in the viewpoint of the SLMK3, I only have to select track 6 on the SLMK3 and can perform there, the Push stays where it is. This behaviour is perfect for someone like me, who performs with more than one MIDI-Controller/-Keyboard. It would be a dream to be able to work so comfortably in Bitwig, but unfortunately in BWS the controllers always affect the others. Is this a problem with the controller script/extension, or is this a problem with Bitwigs controller API?

Regards Andreas

In general, this is possible. But you have to decide on this before startup of the controller. On many controllers it does not make much sense, since you have no idea where you are in the project. Actually, you are the first one asking about this but I see the use-case.
I can add it to my wishlist but this will be very low priority.

This would be sooo amazing to me.

Best regards
Andreas

[AFranke]

No, it is no power issue. I also contacted Bitwig-Support on this. I had to send them the Bitwig log files so they can see there is no issue with the USB connection of the controllers. But I can see in the Controller Script Console that your extension first removes MIDIOUT2 and then immediately adds them again after that. This only happens with Controllers controlled DrivenByMoss, other controllers on the same USB-Hub and physical Port are unaffected. I also tested the Push and SLMK3 separated on different Hubs and different Ports (direct connection to the Motherboard), I tried two different (active of course) quality USB Hubs (around 100 € each) with 70 and 90 Watt power supplies. In addition to that, both controllers also had their dedicated power supplies attached, all the time. In the Controller Script Console, you can also see, that this happens with exclusively to the MIDIOUT2 connections, the MIDI-IN ports of the connection are NOT affected. This is why I come to the conclusion, that this problem has no relation to buggy hardware. I also ran the controllers for some days in Ableton Live and had no problems there, and as I said before, Bitwig support said that the connections of the controllers are stable, and there is no abortion of the connection from Bitwig Studios' view.

Hi Andreas, ein Fehler dazu ist auch in den Logfiles nicht zu sehen. Wie lange hat es gedauert, bis der Fehler auftrat? Das logfile geht von 20:36 bis 22:10? Bei welcher Aktion genau trat der Fehler auf und ist es jetzt vielleicht reproduzierbar?

And if you ask, no I can't force the problem to happen. It happens totally randomly.

Adding and removing ports and devices is totally handled by Bitwig and triggered by the OS. I have no control over this.
One thing to check: I noticed that "since some time" Bitwig does restart all controllers if there is a change on the USB network, e.g. when inserting or removing a USB stick.

Ok, but that's not the case here. I don't have inserted or removed any USB device in this case. And it also does not happen to the other controllers I also have attached, which are not controlled by your extension by the way. It only happens to devices that are under the control of the DrivenByMoss extension.

Nonetheless, now I also added my old APC40, which was laying around here, to my setup. I connected it to another and different port on my computer. I will see what happens to this the next time the problem occurs.

Best regards
Andreas

Moin Jürgen,
maybe a hint? But the controller didn't reset in this case, and worked normal. Maybe another problem.

Bitwig_Studio_8GLtjxcULy.png

Best regards
Andreas

[AFranke]

Bitwig_Studio_ZsxLTx7GN4.png

Ok, it's another problem and I can reproduce it easily.
It happens if I press SHIFT-User on the Push 1.

Best regards
Andreas

[AFranke]

No, it is no power issue. I also contacted Bitwig-Support on this. I had to send them the Bitwig log files so they can see there is no issue with the USB connection of the controllers. But I can see in the Controller Script Console that your extension first removes MIDIOUT2 and then immediately adds them again after that. This only happens with Controllers controlled DrivenByMoss, other controllers on the same USB-Hub and physical Port are unaffected. I also tested the Push and SLMK3 separated on different Hubs and different Ports (direct connection to the Motherboard), I tried two different (active of course) quality USB Hubs (around 100 € each) with 70 and 90 Watt power supplies. In addition to that, both controllers also had their dedicated power supplies attached, all the time. In the Controller Script Console, you can also see, that this happens with exclusively to the MIDIOUT2 connections, the MIDI-IN ports of the connection are NOT affected. This is why I come to the conclusion, that this problem has no relation to buggy hardware. I also ran the controllers for some days in Ableton Live and had no problems there, and as I said before, Bitwig support said that the connections of the controllers are stable, and there is no abortion of the connection from Bitwig Studios' view.

Hi Andreas, ein Fehler dazu ist auch in den Logfiles nicht zu sehen. Wie lange hat es gedauert, bis der Fehler auftrat? Das logfile geht von 20:36 bis 22:10? Bei welcher Aktion genau trat der Fehler auf und ist es jetzt vielleicht reproduzierbar?

And if you ask, no I can't force the problem to happen. It happens totally randomly.

Adding and removing ports and devices is totally handled by Bitwig and triggered by the OS. I have no control over this.
One thing to check: I noticed that "since some time" Bitwig does restart all controllers if there is a change on the USB network, e.g. when inserting or removing a USB stick.

Ok, but that's not the case here. I don't have inserted or removed any USB device in this case. And it also does not happen to the other controllers I also have attached, which are not controlled by your extension by the way. It only happens to devices that are under the control of the DrivenByMoss extension.

Nonetheless, now I also added my old APC40, which was laying around here, to my setup. I connected it to another and different port on my computer. I will see what happens to this the next time the problem occurs.

Best regards
Andreas

I didn't have to wait too long this time. It just happened again. All controllers were removed and added again. Also the APC40, which was on a different Port, without any Hub directly connected to the PC.

Bitwig_Studio_osB2nQr6YW.png

AKAI MPK mini MK3, Arturia Keystep Pro and Arturia Beatstep Pro, which are also connected to the same USB-Hub were unaffected, they are connected via the Bitwig Generic script/extension.

Bitwig_Studio_MCtCnDpS3k.png

Best regards
Andreas

[moss]

Ok, it's another problem and I can reproduce it easily.
It happens if I press SHIFT-User on the Push 1.

Best regards
Andreas

Thanks, will be fixed in the next update!

[moss]

...

AKAI MPK mini MK3, Arturia Keystep Pro and Arturia Beatstep Pro, which are also connected to the same USB-Hub were unaffected, they are connected via the Bitwig Generic script/extension.

Best regards
Andreas

Is this Windows 11?

[mevla]

Is there a transport reset pad somewhere on the Launchpad (Mini) ? There's a stop, but it doesn't reset the transport to 0.

[Frac-Capitaine]

@moss Probably I missed something on your documentation, but with Push 2, is their a way to start the pre-counting/pre-roll before recording a clip ?
Actually when pressing a pad on rec armed track, or with the button "New", the clip start right away recording without pre-count/pre-roll.

[MDicey]

If you know how to build the java code, it is pretty easy to change in this file:
https://github.com/git-moss/DrivenByMos ... nager.java

I think I overestimated my ability to build Java

I followed your tutorial: Bitwig Controller API - Part IX - Developing with Java (youtube.com/watch?v=jSiF7tmkLHE)
While I'm able to build new java controller projects (via Bitwig > Help) I could not manage to build your code from Git Hub to a jar.

My steps so far:

- checkdependencies.cmd runs successfully

- InstallHIDLibrary.cmd is not successful, it give me this error:

Code: Select all

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy-file (default-cli) on project DrivenByMoss: C:\Privat\Programming\Libraries\USB\purejavahidapi\target\purejavahidapi-0.0.18.jar not found

- If I'm attempting to build with mvn install I get this:

Code: Select all

[ERROR] Failed to execute goal on project DrivenByMoss: Could not resolve dependencies for project de.mossgrabers:DrivenByMoss:jar:19.2.2: Failed to collect dependencies at purejavahidapi:purejavahidapi:jar:0.0.20: Failed to read artifact descriptor for purejavahidapi:purejavahidapi:jar:0.0.20: The following artifacts could not be resolved: purejavahidapi:purejavahidapi:pom:0.0.20 (absent): Could not transfer artifact purejavahidapi:purejavahidapi:pom:0.0.20 from/to MavenCentral (https://mvnrepository.com): status code: 403, reason phrase: Forbidden (403)

I tried to build it on two machines, but get the same errror. Could you give me hint what I'm doing wrong?

Thanks again for all your work and sorry for the hassle!

[moss]

Is there a transport reset pad somewhere on the Launchpad (Mini) ? There's a stop, but it doesn't reset the transport to 0.

Press Stop again should do the trick (or press it quickly twice).

[moss]

@moss Probably I missed something on your documentation, but with Push 2, is their a way to start the pre-counting/pre-roll before recording a clip ?
Actually when pressing a pad on rec armed track, or with the button "New", the clip start right away recording without pre-count/pre-roll.

The "New" feature has no count-in since it directly creates a clip and overdubs it. There us no way to implement an overdub for this.
If you start clip recording by tapping an empty clip in the session view instead, you get the count-in.