[BUG] JamStix stops playing under Ableton - long post
Posted: Tue Dec 29, 2020 10:05 am
When JamStix is minimized and "playing" silent/silent, after one bar the software stops playing.
What happens is Ableton sends the VST request for processReplacing.
audioMasterGetTime it looks like is triggered by JamStix as part of the response to this.
Because there is no UI, there is no effEditIdle to trigger audioMasterGetTime, so after 1 bar of no replacing Ableton quits querying the plugin.
When the plugin is visible, there is a constant stream of effEditIdle which keeps the plugin alive, and if the plugin is creating a beat, processReplacing returns a valid buffer so I assume this keeps Ableton interested.
Also, when the play/stop/timebar edit in Ableton occurs, the dispatcher ProcessEvents request is sent to the plugin, which wakes everything up too. It's only when there are several bars of silence at the beginning of a song and JamStix is minimized that this occurs.
Personally I don't care too awful much, I have a constant stream of recompose midi requests going which also keeps the Ableton/Jamstix connection going, but I did want to report this as a bug.
I can see all this by running a plugin I'm building that acts as both a host to JamStix and a VSTi loaded by Ableton, and proxies all the calls b/w Ableton and JamStix so I can poke my own information into the object returned by audioMasterGetTime to fix the JamStix/Ableton behavior of live looping. My preference would have been a working livelooping, but the rest of the plug is so awesome that taking the long route to fix this is worth it! If you would like, I can submit the code when I'm done, maybe the logic can get rolled into JamStix as a patch for live looping.
What happens is Ableton sends the VST request for processReplacing.
audioMasterGetTime it looks like is triggered by JamStix as part of the response to this.
Because there is no UI, there is no effEditIdle to trigger audioMasterGetTime, so after 1 bar of no replacing Ableton quits querying the plugin.
When the plugin is visible, there is a constant stream of effEditIdle which keeps the plugin alive, and if the plugin is creating a beat, processReplacing returns a valid buffer so I assume this keeps Ableton interested.
Also, when the play/stop/timebar edit in Ableton occurs, the dispatcher ProcessEvents request is sent to the plugin, which wakes everything up too. It's only when there are several bars of silence at the beginning of a song and JamStix is minimized that this occurs.
Personally I don't care too awful much, I have a constant stream of recompose midi requests going which also keeps the Ableton/Jamstix connection going, but I did want to report this as a bug.
I can see all this by running a plugin I'm building that acts as both a host to JamStix and a VSTi loaded by Ableton, and proxies all the calls b/w Ableton and JamStix so I can poke my own information into the object returned by audioMasterGetTime to fix the JamStix/Ableton behavior of live looping. My preference would have been a working livelooping, but the rest of the plug is so awesome that taking the long route to fix this is worth it! If you would like, I can submit the code when I'm done, maybe the logic can get rolled into JamStix as a patch for live looping.