Ableton Push support is here

[Dunder]

Do you have any idea of when you will come round to implement the Doubble button?

I looked into this but it is still not possible with the current API (also in 1.1).

That is sad. But if you can get this clone functionality up and running, it will replace most of the purposes of the duplicate/double button

One more thing I noticed: In the last version of the script (3.3 I think) using the horizontal arrow buttons in session view made it jump 8 steps. In version 4, it only jumps one step, and jumps 8 step if you hold down the shift button.

I think the 3.3 implementation was better, since you mainly use the arrow keys for navigation, and top 8 buttons for track selection. I think the most optimal implementation is that (without shift pressed) vertical buttons moves the view 1 step and horizontal buttons move the view 8 steps and shift inverts the behavior.

[hibidy]

I got another question that might seem remedial but I can't figure out if it's something that can't be done or I just don't understand how to use bitwig/push right now:

Can you get bitwig to have let's say "maschine 2.1" software show up with just the 16 pads. In live this is easy of course, but wasn't sure if it's possible in bitwig. If not, is it possible to have the pads default to "chromatic" so that the push pads are all available and you don't have to change in "scale?" (not that that is a biggy, just wondering)

[moss]

Can you get bitwig to have let's say "maschine 2.1" software show up with just the 16 pads.

Do you mean opening the Maschine VST UI? If yes, this is currently not possible because it is not in the API. It is on my wishlist too.

If not, is it possible to have the pads default to "chromatic" so that the push pads are all available and you don't have to change in "scale?" (not that that is a biggy, just wondering)

In the new version for Bitwig 1.1 this can be set in the preferences.

[hibidy]

Thanks!

[thetechnobear]

sequencer mode working - Im finding the 'playhead' is not in the correct position 1/2 bar at least behind where it is in the clip in BWS (or the notes being played )

also i had a oddity, where i didnt seem to be able delete a clip in the session view on the push.
(its worked ok at other times)

thanks
Mark

BWS 1.1b6 / latest version of Push scripts from github

[TeotiGraphix]

sequencer mode working - Im finding the 'playhead' is not in the correct position 1/2 bar at least behind where it is in the clip in BWS (or the notes being played )

also i had a oddity, where i didnt seem to be able delete a clip in the session view on the push.
(its worked ok at other times)

thanks
Mark

BWS 1.1b6 / latest version of Push scripts from github

The first problem probably is a refresh issue, other than optimizing down the road, it is what it is, we get the current step from the controller API.

You can ONLY delete clips if they are selected in the session view inside Bitwig, this is a bug sort of with the API right now.

Mike

[thetechnobear]

The first problem probably is a refresh issue, other than optimizing down the road, it is what it is, we get the current step from the controller API.

hmm, not sure… it didn't improve when i switch down from 1/16 to 1/4.
id assume if it was a refresh issue, then it would be much closer at slow rates due to having to update less frequently - no?
( I also tried stop/start transport, and its out of sync from the outset, almost like its incorrectly offset)

You can ONLY delete clips if they are selected in the session view inside Bitwig, this is a bug sort of with the API right now.
Mike

ah, ok, so hopefully they are on to it.

[TeotiGraphix]

> hmm, not sure… it didn't improve when i switch down from 1/16 to 1/4.

I meant a refresh from the API, Bitwig calls observers and the step they send may be lagging for some reason.

I haven't looked at the code yet, moss can chime in if he knows something I don't.

Mike

[moss]

I haven't looked at the code yet, moss can chime in if he knows something I don't.

Yes, Mike is right. The steps ("clock") coming from the Bitwig API is laggy and "jumpy" as well. I did a lot of experimentation with that trying to built sequencers running in the script (which failed and now I always use midi clips as the basis).
I guess the simple reason is that the scripting engine is runnning low priority instead of the audio process (which makes sense).

[hibidy]

I have no idea what exactly you are talking about, but you rock anyways

Hopefully I'll have my license and be able to apply for 1.1b6 soon, but while I use the demo, push seems to be working nicely. In many ways, better than it does with live

[thetechnobear]

I haven't looked at the code yet, moss can chime in if he knows something I don't.

Yes, Mike is right. The steps ("clock") coming from the Bitwig API is laggy and "jumpy" as well. I did a lot of experimentation with that trying to built sequencers running in the script (which failed and now I always use midi clips as the basis).
I guess the simple reason is that the scripting engine is runnning low priority instead of the audio process (which makes sense).

ouch, thats going to make the callbacks of pretty limited value... its going to rather limit what we can do with the data, as its always potentially 'out of date'.
I accept that you cannot have this running at audio rate priority, as it cannot affect the audio engine, so a lower priority is ok, but being behind by multiple beats seems a little 'excessive'

@dom/thomas is this a known issue that is going to be fixed?

btw, moss i think your right about putting the data in the clips, id say if it was to be separated it should be written as a device... but then one could argue you may as well use a vst based sequencer.

one other thought, 'user mode', I think this could be an interesting 'addition' so that other push helpers can be used. e.g. I use Liquid Rhythm and Numerology. both of these use the user port directly, but perhaps we could talk to them about an 'agreed' switching system, e.g. hold user + track select, determines which actually reads/writes the user port. or an alternatively, e.g. someway to 'disable' per track.
its already a slight issue in Ableton, if you have multiple 'user port' sessions.

Id just like to say again, I think this push controller work is fantastic, especially considering the limitations of the API... its a great job, well done, and a big thank you too

[ThomasHelzle]

For the moment the JavaScript API isn't meant for timing critical tasks but mostly for twisting knobs and stuff where it's not about microseconds. That is why note data isn't handled by the API but goes directly to the engine, the note commands are more pointers to the functions there.
The same is true for feedback, which ATM is not meant to be used for timing critical stuff but more to keep stuff roughly up to date, like a motorfader.
The things you guys are talking about may need a different API, maybe written in C++
The thought exists, but this won't come any time soon.

You are welcome to send the issue with clear repro steps to support so I can forward them and see if something can be done to at least improve it.

Cheers,

Tom

[thetechnobear]

For the moment the JavaScript API isn't meant for timing critical tasks but mostly for twisting knobs and stuff where it's not about microseconds.

( my emphasis)

that was kind of my point, it didn't even feel like microseconds, more like 1-2 seconds.
I think the aim should be for a callback at least at 1/32 beat.
of course its up the controller script write to ensure they don't start doing huge amounts of processing.. though with the right priority, this still would not affect the audio processing threads in bitwig as the controller callback thread would be preempted.

(as an aside, this is possible in Live controller scripts, and I'm sure if I want I could write a controller script that would have adverse affects on live… just there wouldn't be many users wanting to use it, and they would (rightly) blame me, not Live for the poor performance)

a c++ api would be cool for me but would really limit the uptake, and i think is a bit more suitable for audio rate processing, rather than fairly simple controller interaction.
(also doesn't bitwig use java internally, so id guess for non audio rate stuff, this might be a better interface)

anyway, sorry this is probably all OT …

back on topic, perhaps the push controller should remove the playhead for the time being, as its misleading/confusing

[taoyoyo]

One thing that would be handy would be if it was possible to somehow get the Ribbon (in Session/Crossfader mode) to be able to center exactly to zero (not sure if there's any 'double-tap' or 'touch sensitivity' available to allow that?)

You can now press Shift+Ribbon to center it. If you can try it with the 1.1 Beta 6 and the current GitHub Trunk.

Cool, thanks Moss... working great in B8!

[crocronico]

Hi: thanks for this great script!
I think with it, I will switch to Bitwig ^^(it's so powerfull..)
I have two request.

The first one :
In ableton , I play my liveset with two push in session mode (the 8 first scenes (1to in the push1 and the 8 next scenes in the push2 (scene 9 to 16).
I can't get 2 push working in bitwig.Can you make something for that (it work on ableton)?

Second request:
On my liveset, I scroll down (in ableton) to next scenes grid just using octave up or octave Down btn (to scroll 8 by 8 in just one click: ). It don't work with your script but it will be great too.

Thanks for your support !