Closed pgatt closed 4 years ago
Hm, are you aware that loading a new patch would also unload the module itself?
Yes but what would stop me from having another instance of the module in the next patch with a different file chosen but with the same midi input making the trigger happen. A bit Patch-ception I know.
By the way totally understand if it’s too crazy or wouldn’t work or is not in line with your pack.
I will check if it possible. A crazy idea indeed :-) One question about the workflow: Is the next file pre-selected and stored within the parch and loading is delayed until a trigger is received?
My thoughts of how it could work was the module would be saved with a link to the patch file that would be the next in the sequence but it would wait until it received a gate to close the current patch either with or without saving and then launch the new one.
I investigated Rack's code yesterday and it should be possible without much effort, I estimate 4 hours of work to create a panel, write necessary code and test it. May be called EXIT.
That is so awesome! Thanks Ben! What about “stage left” for a name?
On 8 Aug 2019, at 7:23 pm, Ben notifications@github.com wrote:
I investigated Rack's code yesterday and it should be possible without much effort, I estimate 4 hours of work to create a panel, write necessary code and test it. May be called EXIT.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
Is there any update on this Ben?
I added module EXIT in the latest commit, but I'm not conviced I'm going to keep it. I had many crashes due to synchronization with Rack's engine while debugging. These crashes doesn't seem to appear in the release version of Rack. Feel free to test it and let me know if it works reliable for you.
No it crashes here too. That’s a shame, still love the idea of it.
On 13 Oct 2019, at 10:41 am, Ben notifications@github.com wrote:
I added module EXIT in the latest commit, but I'm not conviced I'm going to keep it. I had many crashes due to synchronization with Rack's engine while debugging. These crashes doesn't seem to appear in the release version of Rack. Feel free to test it and let me know if it works reliable for you.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
Log file if it helps.
https://www.dropbox.com/s/hdz5lbrvh193c1x/log%202.txt?dl=0
On 13 Oct 2019, at 10:41 am, Ben notifications@github.com wrote:
I added module EXIT in the latest commit, but I'm not conviced I'm going to keep it. I had many crashes due to synchronization with Rack's engine while debugging. These crashes doesn't seem to appear in the release version of Rack. Feel free to test it and let me know if it works reliable for you.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
It is quite easy to initiate the loading of another patch but I hadn’t considered how crucial the right timing would be. The problem is that Rack‘s engine thread is right in the middle of processing an audio frame when loading is triggered from a module and the engine does not like that. Same problem when loading from the GUI thread. The right moment would be between two frames on the GUI thread but I’m not sure if it possible. There is no API for that but I will think about it.
I'm sorry to say but I have to drop this idea. The only way I can think of getting this stable would be by hacking into a component of the menubar which is rendered out of the context of the modules and widget. I really don't want to do this.
Hi Ben,
That's a shame but thanks so much for trying to make it work.
On 18 Oct 2019, at 6:06 am, Ben notifications@github.com wrote:
I'm sorry to say but I have to drop this idea. The only way I can think of getting this stable would be by hacking into a component of the menubar which is rendered out of the context of the modules and widget. I really don't want to do this.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/stoermelder/vcvrack-packone/issues/40?email_source=notifications&email_token=AAAGIT3J76E5W5RR45MVHPLQPCZSZA5CNFSM4IJ2X522YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBRGADY#issuecomment-543318031, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAGIT2YLVGHMR2VQTF335DQPCZSZANCNFSM4IJ2X52Q.
As I said before: Rack v1 has no API allowing such a thing, but working around it through the menu bar is possible. I did some experiments on the menu bar today and ended up reviving this idea. I added module "EXIT" in the latest commit of PackTau as it should considered experimental, but I seems to work stable, no crashed on my side. Actually, how it is implemented now is not far from clicking "Load" in the menu bar itself. https://github.com/stoermelder/vcvrack-packtau/commit/bcf78e96fc65ed9161235bfa334f9371377df156
Woah. Nice one Ben! Will give it a test today!
Hi Ben, I thought of an idea for a module and I thought VCV’s resident wizard might be the person to ask if it’s possible.
What if we had a module that took two triggers in - one to close the current patch with saving, one to close without saving, and then a file selection input to select the patch you want to open after closing the current one.
The reason I ask is that I would like to sequentially open patches for individual songs and then close and open the next one via a Rack trigger.
Thanks for the consideration.