@dag2099 Im interested. Also Im specifically interested in the turing part.
1 Like
Patch Documenter
As someone who shouldn’t ever be allowed to code anything, I may talking out of an orifice here. But with each patch consisting of a file that contains things like plugin collection, names, and versions, along with parameters for each plugin, I would think a plugin that creates a snapshot of a current patch and outputs it into something readable would be simple. Maybe something that looks like this:
Patch Name: My Freakshow of a Patch [taken from the file name]
Module 1: AudioInterface v1.1.6 (Core)
Paremeters:
deviceName: Focusrite USB ASIO
maxChannels: 8
sampleRate: 44100,
blockSize: 256
Module 2: VCO v1.4.0 (Fundamental)
Paremeters:
id: 0
value: 1.0
id: 1
value: 1.0
id: 2
value: 0.0
id: 3
value: 0.0
id: 4
value: 0.0
id: 5
value: 0.5
id: 6
value: 0.0
It would be nice if those IDs had something more descriptive but it’s easy enough to figure out and non-coders can’t be choosers.
Something that autosaved based on a chosen schedule would be great, too.
A TXT file would work. Something prettier would be better/more of a hassle to create (I’d imagine), but a PDF would be great. If it could also capture an image of the patch (no idea how that would work) that would be spectacular. And a PDF containing those images along with the documentation? Well, that would be perfect.
The .vcv patch format is JSON. Just use that.
Yes, the JSON was what I used to come up with the info posted above. And I can either convert the JSON to something else or just read the JSON file myself. But the idea was for a module that you could add to your patch, click a button, and have that JSON file converted into something not just human readable but, maybe, elegant. I probably could have been clearer about that.
You could convert autosave.vcv to yaml in the command line
Yaml is a bit easier on the eyes, but I don’t get why you want to read a patch in the first place, it’s hard to make sense of the textual data on its own especially cabling, which is a defining part of any patch imo.
This idea of extracting data from patches is likely to become more useful after the new zip format comes into effect in v2 (https://github.com/VCVRack/Rack/issues/1807). Those interested in knowing which modules they use most frequently (stoermelder's Idea und Development Thread), or desiring to search for a patch or patches with a given label or some other characteristics could use such output as an alternative to decompressing all their patches to get at the data.
1 Like
cson is another very-human-readable serialized format, even more IMO than yaml. I wish it was more popular.
4 Likes
You linked to my comments 
If you are talking about patch stats, I’m all for it. Better summarize as a module idea.
Patch browser module
Similarly to how the MB from Stoermelder works, one can imagine a patch browser module as well. When clicked it opens a floating widget, with the patches folder, showing list of patches.
When one is selected, a summary is shown with
- a screenshot (rendered on the fly)
- number of modules and cables in patch
- creation and modification time
- if the patch contains Fundamental Notes, the text from it shows up as a description
- warning about missing modules
The listing of patches can be ordered by some of the former properties.
A couple of actions that would be useful
- save/load/clone patches
- filter patches by what module(s) they contain
There’s also a “Stats” tab, with overall statistics. Below some examples of what to get out from patch files only
- Activity timeline similar to the activity curve on github, based on the timestamps of the files
- Total number of patches, modules and cables used
- Approximate area covered by modules in squaremeters, and overall cable length in meters
- Most used modules
- Most used cable color
additional stuff
- show Strip save files in a similar fashion
- when a patch is selected find similar patches based on the modules used.
- change folder
6 Likes
Here it is. Sorry for the wait:
I didn’t make this on stream but i did make the previous example here https://www.twitch.tv/videos/727779627. It’s unedited though.
2 Likes
This is all great stuff. I’m in.
yesterday Andrew was playing piano on Dexed Vst on his live stream, I m not sure if someone mentioned it here, but
FM Algorithm
it could be a module with four to six VCOs inputs and fm output, four to six envelopes options (Knobs and/ or CV) and Audio out
the workflow:
-
Select the number of CVOs in the patch
-
for every VCO you should connect the VCO audio signal OUT and the FM input.
-
for every VCO connect a Gate and tweak the envelopes.
-
select the FM algorithm to use.
-
play a Synthwave song
edited: could be possible make it capable to load DX7 patches?
1 Like
Someone is already doing this.
1 Like
cool , super nice!
thanks for the link!
also the now ancient “dexter” from valley is exactly this, isn’t it?
can you feed the dexter with external VCOs?
super late reply, but I get a lofi distortion effect vaguely like “disintegration loops” by using red noise (from fundamental Noise module) to control the drive amount on a VCF. Passing the noise through a wave shaper, and/or a VCA controlled by BogAudio Walk gets a very nice, controllable effect.
In general, modulating sound processors with filtered noise is a way to add grit.
2 Likes
Yeah I’m also interested on this, or some other module that does FM taking arbitrary carrier and modulation signals. I’ll start to code if there aren’t 
I don’t think it’s possible to modulate an arbitrary carrier. the FM is induced while you you are generating the carrier. I must be misunderstanding here.
Most FM modules take an arbitrary (external) modulator. FM OP is the most popular. (although my Kitchen Sink does more 
1 Like
Yeah, you can AM/RM any two arbitrary signals, but the frequency modulation happens inside the synthesis of the carrier.
2 Likes
Isn’t FM Linear type (i.e. affect frequency directly) a sort of FM? What if I modulate a frequency shifter so? Couldn’t be considered a sort of Linear FM? 