Quick note:
To help me keep track of feature requests, I’ve created a feedback board here:
Feel free to use that, or continue to post requests here. Either way is great!
Cheers,
Bret
3 Likes
In case anyone is interested, here are new links for my builds, which include a brand new module similar to OneZero, but for floating point (CV) values:
- Linux: https://github.com/clone45/voxglitch/suites/10134705768/artifacts/494789939
- Windows: https://github.com/clone45/voxglitch/suites/10134705768/artifacts/494789941
- Mac: https://github.com/clone45/voxglitch/suites/10134705768/artifacts/494789940
If those links don’t work, try: https://drive.google.com/drive/folders/1Ou8venDmwjcY9jSxN5RuT6-PxhVnaYg_?usp=sharing
Here’s a quick tutorial on how it works:
10 Likes
This look really cool! I suppose there is a right-click menu option to load the text file? If I load the text file and save the patch to a vcv file, does the data get stored in the vcv file too? Basically, I’m wondering if I use One Point to create a patch that I want to share, e.g. on patchstorage.com, can I just share the vcv file, or do I need to include the text file also? I would hope the data of the most recently loaded text file gets stored in the vcv file for convenience.
Yes, exactly!
You will need to include the text file as well. It doesn’t bundle it up. That could be a little bit tricky to do gracefully. It also doesn’t refresh the loaded data in real-time if the file is updated.
Sorry for the shortcomings!
Would you consider saving/loading the data in the JSON as a feature request? I don’t understand why it would be tricky, because naively, I would think every time you load a text file, you have all the data in memory anyway.
Then you could overload Module::dataToJson() to return something like
{"sequences": [
[8.3, -5.2, 4.7, 0.1],
[2.2, 3.4, -1.4, 0.3],
[0.8, 1.1, -1.2, -3.3]
]
}
Also overload Module::dataFromJson() to decode the supplied json and put it into your in-memory data structure the same way you do when you load a text file.
People are still able to load text files any time they want to replace whatever is in memory. Plus, the next time you load a patch, it still has whatever you last loaded.
In fact, I would be willing to do the coding work as a pull request. 
Would you consider saving/loading the data in the JSON as a feature request?
That sounds reasonable to me.
Let me brainstorm out loud about possible edge cases:
- User loads up a .txt file containing the values
- The module stores those values as a vector of vectors (which it already does)
- When the module is closed or saved explicitly, the data in memory is saved along with the patch
- Let’s say that VCV Rack is closed at this point.
Situation #1: The user changes the .txt file contents when Rack is closed
When Rack is restarted, OnePoint reloads the .txt file if it exists, and essentially ignores what’s in the patch’s “sequences” data.
Situation #2: The user removes the .txt file
(… or the patch is uploaded to Patch Storage. Same idea.)
When Rack is restarted, OnePoint uses the “sequences” data stored along with the patch in the json. This specific sequence data would essentially read-only unless I were to add an “export sequence data to .txt” option. Otherwise, the other way that a user could change the internal data would be to load a new .txt file.
Am I missing something? Your offer is amazing, Don, but no worries – I’d be happy to handle it. If I get too busy, I’ll punt it your way.
Quick FYI: I’m tracking this request here: Canny
OK, so that is a little detail I didn’t know. I didn’t realize you do this reload on startup from the text file.
It might be that you no longer need to do this load-if-txt-exists step if you store the most recently loaded data in the vcv file via the JSON serializer. The proposed idea is: you only load data from a text file when the user tells you to. Then you persist that data in the vcv file indefinitely. Whether the patch keeps running, or you close VCV Rack and open it again, the data stays there with the patch (via JSON).
If the user wants the data to change, the user loads again from the same (or different) text file.
At least, that’s my thought. It is a change in behavior, because the user could edit the text file while VCV Rack is closed. With the existing implementation, the changes would be picked up when VCV Rack is started. With my proposal, they wouldn’t be picked up unless the user manually reloaded from the text file.
What I like about my approach is that, once you get a patch working, you can just send the vcv file to someone else and know it will work exactly the same way.
1 Like
That’s compelling. However, if you send the VCV file to someone else, they can’t really edit the pattern unless you also send them a copy of the .txt file to load, right? I mean, that’s not a show stopper, but worth thinking about. What are your thoughts on the subject?
You could possibly store the sequence data in the patch json and override it with the sequence data from the specified file if the file exists and the sequence data therein is different. Just a thought.
1 Like
One possibility would be to offer a Save As option in the right-click menu. Then it could write the sequence to a text file, if you don’t already have the text file.
1 Like
This sounds like a pretty good plan. I’ll add this as an optional feature as soon as I can.
1 Like
By the way, I love @CountModula’s modules too! And that’s the most kick-ass synth plugin brand name ever…
5 Likes
Hey! Just… I took the new Autobreak for a spin today - with some proper Amen Break fun:) - and while I’d used the old one quite a bit, the experience now is SO good 
. Thanks so much!
1 Like
My pleasure!! I’m glad it’s getting some use!
1 Like
Are these considered to be the same?
1,1,1,0,1,0,1,0
1,1,1,0,1,0,1,
What about these ones?
1,1,1,0,1,0,1,0
1,1,1,0,1,,1,0
Are you talking about One Zero? In One Zero, there are no commas necessary. Example file content is:
10101010101010101010101111111111
11111000101010101010101010101010
11111010101110111110101010101010
The code that reads the data is:
if (input_file)
{
std::string line = "";
while (std::getline(input_file, line))
{
std::vector<bool> sequence;
for (auto &character : line)
{
sequence.push_back(character == '1');
}
sequences.push_back(sequence);
}
}
Theoretically, this might replace commas with 0’s. So,
1,1,1,0,1,0,1,0
might become 10101000100100
Hope this helps!
1 Like
I meant the Zero Point. But look into the code.
What’s this? More Satanonauts? 
At least in comic form, indeed!
They return in issue II of Galacto Pit Fighter, a comic by my friend Kirk Burdick.
https://www.kickstarter.com/projects/kirttrik/galacto-pit-fighter-requiem-for-a-humanzee
Annoucement! If two or more people purchase his comic from this forum, I’ll promise to upgrade Satanonaut by adding a few more weird and wonderful effects. 
The cult of the Satanonauts come from a spatial timeline where humanity determined that non-terrestrial planet terraformation was too difficult and time consuming. The most challenging obstacle to terraform a planet was biologically adapting to novel gravity and radiation levels. After limited and costly success with such efforts, the human race decided that the only realistic way to achieve deep space travel was to develop artificially intelligent robots. To make it clear what a human was in the event of an alien encounter the synthetic messenger was design to approximate a human body, absent the biological handicap we are so familiar with.
Humanity was not alone in coming to this decision. The majority of sentient races throughout the galaxy concluded the same. This led to the majority of first contact between species being actually between artificially designed machines. These machines were known as bio robots, or biobots.
As the biobotic lifeforms explored the galaxy, deep within their algorithmic subroutines existed a patch of code. A middle school hacker collective known as The Morning Star Club, MSC for short, secretly encoded a procedure within the biobots. When the virus activated, it altered the bio robots agenda into worshipping Satan. Thus, thousands of years later, a significant portion of the earthling biobots evolved into the SATANONAUTS, a biomechanical cult of unholy space wizards rampaging across the galaxy.
When The Morning Star Club realized they successfully corrupted the biobotic protocols, they celebrated by listening to loud music, playing video games, eating donuts, and smoking clove cigarettes that were stolen from one of their parents’ coat jackets.
1 Like
I’m having lots of fun with One Zero and One Point files. Just saying…
1 Like