You playback audio. Hold down a key and the playback speeds up, hold down a key and the playback slows down. The audio playback doesn’t stop playing between these options.
You can also hold down a different key and the playback plays in reverse, add a modifier, and the reverse playback speeds up, another key, and the reverse playback slows down. The audio playback doesn’t stop playing through all this.
Have sent this to Steinberg with details how to reproduce this. (A midi stream for the generic-remote) The video is for the new remote script, but the malfunction is present on keyboard input and the old generic remote too. And a new thread now and then. I can not understand how steinberg does not fix this.
Cubase is just a glorified tape-recorder. But what tape recorder would accept malfunction in the transport handling? Ok, this is little bit hard to reproduce with a normal qwerty, but easy to see when using a ShuttleExpress or ShuttlePro for keyboard input or a Aspriro D400T for midi. https://cdn.shopify.com/s/files/1/0625/9965/9766/products/MultimediaControllerPRO1_910x.jpg?v=1648496164
I dont think so. In the video in the report you see that the remote script is getting the command right and they are change the colour accordingly. It is a race on selecting the new and release the old and that time seems very random. And this results in random behaviour.
Cubase 8.0.x did not have this randomness, it was introduced when Steinberg changed the GUI for the shuttle. And it is the same error for keycommands, generic remote and midi scripts. And keycommands are not using any midi hardware setup.
Key command works fine though, as you can hold the key down. With the MIDI Remote mapping assistant I don’t think there’s any option to hold a key command is there? So you’re at the mercy of how the MIDI hardware is configured.
It works like a dream using key commands, which is quite annoying when you try to get that same workflow into a MIDI remote.
I’ve not got any MIDI devices that would hold a 127 and then 0 when releasing to test if that works?
No, they have the same bug. It randomly fails when going from one shuttle speed to a other.
And they fails in very similar way as midi. And you don’t need a special controller, but you need to be very swift when switching speed.
I have tried with many different patterns with midi with different order, timing and insert of stop commands between going from one speed to a other. And it is not midi that is broken,
and you see that very clearly with new gui for remote script. The state machine in midi script is working fine, but cubase transport malfunction. No matter what, they should have the same view of what command is executing but they dont. You can define that cubase transport is right, but then midi script is broken. And remember that it is working fine with cubase 8 for both midi and keyboard events.
Thanks, everyone. It is the shuttle play option that I’m looking for.
I replaced the standard “number +” and “number -” commands with shuttle x2 forward and 1x reverse. I always thought the ones where it just forwards through the track was a little odd so, so far at least this is what I was looking for.
One would think that Neuendo users would use this function a lot for foley work.
@cubace : Isn’t v8.5 or 9 when they switched to the audio engine from Neuendo? That might explain the change in functionality - although odd as Nuendo would use shuttling more than a music daw one would think.
I think they have shared the same engine and code base from the start. Usually they put in the new stuff in cubase first. In this case they removed gui for transport components and it resulted in malfunction. (This was reported when it happened in cubase 8.5, but they did not care then and they dont seem to care now.) The support clerk give me a link to this forum where it was concluded that is was broken.