I’m currently developing a controller script for Bitwig Studio 5.1.8 using API version 17 (loadAPI(17)), and I’ve come across what I believe is either a bug or at least a very unexpected behavior in the API.
Issue summary:When calling clip.scrollToKey(pitch) in my script, any subsequent calls to clip.setStep(channel, step, pitch, velocity, duration) result in the written note being transposed +60 semitones (+5 octaves), even though the pitch value passed to setStep is correct (e.g., MIDI 60 for C3).
This issue happens on different tracks, with various instruments, and even on empty MIDI tracks with no instrument loaded.
Expected behavior:clip.scrollToKey() should only affect the clip editor’s visual scroll position and must not modify the pitch data written by clip.setStep().
Reproduction tests (all tested with clean setups):Test 1: Minimal script (no scrollToKey) – works fine
ts
Copy
Edit
clip.setStep(0, 0, 60, 100, 1.0);
Result: A C3 (MIDI 60) note appears in the clip. Test 2: My main script without any clip setup (except exists().markInterested()) – works fine
Result: C3 is written as expected.Test 3: Same script with full .markInterested() for all clip properties, but still no scrollToKey() – works fine
Result: C3 is written correctly.Test 4: Only scrollToKey(60) called before writing the note – bug appears
ts
Copy
Edit
clip.scrollToKey(60);
clip.setStep(0, 0, 60, 100, 1.0);
Result: A C8 (MIDI 120) note appears in the clip 
Even with all other setup calls removed and scrollToKey() being the only active setup line, the issue persists.Test 5 (control): All setup calls active EXCEPT scrollToKey() – works fine
Result: Pitch 60 (C3) appears correctly in the clip.
Conclusion:clip.scrollToKey() seems to trigger an internal shift or misalignment that causes subsequent clip.setStep() calls to be transposed +60 semitones, regardless of the pitch value passed. This makes it very difficult to use scrollToKey() in combination with pitch-based note writing logic.
Current workaround:Avoid calling clip.scrollToKey() in the script. This avoids the pitch shift, but of course prevents programmatic scrolling of the clip view.
Request:Could someone from Bitwig (or in the community) verify whether this is:
A known bug in API v17?
An unintended side effect that could be fixed in a future release?
Or is there some undocumented state change introduced by scrollToKey() that we need to reset manually?
I’d really appreciate any insight, explanation, or fix. Let me know if logs or further test code are helpful – I’ve got all of it documented.
Thanks a lot for your time and support!
Best regards,
Frank
