That’s a great idea, but too much work to make it into this upcoming release. I’ll put this on my to-do list!
I have! But I haven’t taken the time to make it happen yet. I have some spare time today and I’ll see if I can put something together.
I could add Next/Prev memory buttons to the Groovebox and move the Copy/Paste functionality into a context menu for the memory buttons? However, I wouldn’t be able to get this done by the next release. I really like the idea though!
I know true level-matched AGC can be tricky to implement, but you could always just do a “dumb” compensation, where X amount of signal drive = X amount of attenuation, whenever you get around to it. Thanks as awlays!
I’ve started working on this and I’ve gotten this far:
The next step would be to offer a “Load Kit” menu item. This would prompt you to choose the .kit file to load. I imagine that the module would de-compress the .kit file into a folder. However, here’s where things get a bit foggy for me… Where should the .kit file be de-compressed?
I think that I might be missing something obvious. Maybe there’s a more graceful way of doing this? I’d love to hear your thoughts!!
Cheers,
Bret
I would say in the folder where the patch file is located.
Or you could ask the user for a location (just as you did when saving the .kit file)
Joop
I think that I’ll be taking this approach. 
Ok, as requested, I’ve added the ability to export and import sample data from Groovebox! Tonight I hope to get a new update submitted to the library. 
Awesome re Kit export/import. Big win.
Yes, we had a similar concept in mind. Having played around with the module a bit more, I think it’s fine to add a couple of them and merge them to a polyphonic cable.
One other thing: would it be possible to reload an updated txt file without using the right click menu and file dialog? That would make it a lot easier to listen to changes on the fly without so much interruption.
Sure, I’ll see what I can do. It might take a little while, so bear with me!
I just caught a bug with Autobreak studio. I can’t replicate it though. So I had this setup
And when I tried to change the PAN on the 4th step, VCV crashed unexpectedly. I am trying to do it again, but it works fine now. Weird!
BTW! The buttons NEXT and PREV here would be also a very good idea! wink wink
If you can get it to crash again, the most helpful thing you can do for the developers to fix it is, don’t start VCV Rack again. Please first grab a copy of the log.txt from your user directory and upload it here as an attachment. After the log is captured, then you can run VCV Rack again.
Once you run VCV Rack again, the precious diagnostic information is overwritten. So hopefully you can get it to crash again so someone can figure out what went wrong and how to fix it.
A new light shines, this is an incredible tool. Thanks for the spotlight.
We can CV control the seq selection, not just next or prev? Laundry Soup extravaganza plus if so.
That’s true, but I agree that next/previous buttons might make sense as well. I can also move the copy/clear functionality into context menus for the memory buttons, which I’ve been moving toward, to make room for both buttons and CV inputs for previous and next. I’ll put this on my to-do list.
Yeaaah, I know. I was concentrated on a song, I had to start the music again as fast as possible so I would remember what I wanted to do. I am like a goldfish, I forget things instantly if I don’t document them in any way. Have you seen “Memento”? That’s my life, haha. Notes everywhere and I don’t remember what some of them mean.
Anyway, I think it would be nice if VCV archived the old log files somewhere or when starting after crash the dialog window should have an option to copy the previous log, so it would be easier to report a problem.
I second that!
I suggested this a couple of hours ago in an email to VCV Support: when a crash is detected from the previous run (lack of an “END” line in log.txt), rename the previous log.txt to crash.txt before starting a new log.txt. So they have the idea in the pipeline now.
Having drum sequences shift under the control of CV while preserving their location in the timeline is massive. That saves so much time in creating interesting grooves on the fly. A true LIVE tool.
Thanks again Bret for always listening.
Hi everyone,
I was creating music a few days ago and realized the I wanted a slim, POLY sample player. I’m calling it the “SP-16P”, meaning “Sample Player 16 POLY”.
At the moment, it’s very bare-bones, but I may eventually add poly inputs for controlling pitch, volume, and pan.
I’ll be releasing this module eventually! Right now it’s in my main branch, ready to go. But I might want to sneak in some more development before bothering the VCV Rack build crew with another update.
You know, I was thinking about Autobreak, cause I use it a lot recently and it would be super cool to have a way to record something on the go and put it into autobreak. Not sure if it’s possible, but this post reminded me of this for some reason, haha
