thank you very much
1 Like
A Magic Trackpad midi-cv interface pressure-sensitive and position
give you the ability to control parameters with position or pressure while touching (not click) over parameters. like Sail - stoermelder *I’m talking about External Magic Trackpad 2 but macbook trackpad can do this as well)
Max4live external(FingerPinger) on the ability of a trackpad (I know its not C++) https://www.anyma.ch/2009/research/multitouch-external-for-maxmsp/
1 Like
The Sensel Morph API exposes all this data (and more). The question is what to do with it. With the Innovator’s Overlay, of just the bare Morph itself, you can map areas and define actions for what you want to do with the data from touching those areas (velocity, aftertouch, X and Y gestures). Do you want to do something other than that with the data, or do you just wish to extract it from trackpads and do the same with it (I think the Mac Trackpad has 4 force sensors as opposed to 20K on the Morph). http://guide.sensel.com/api/
3 Likes
Nobody said you can’t dump the craziest ideas possible nobody will ever bother to implement in here, with zero clue about the algorithms to use, right? Ok here goes:
Virtual Voltage Rectification (or VVR for short).
The module displays an animated Dance Dance Revolution-style stepchart of arrows to hit in sync with sources of voltage from the rack, and if the arrows are hit in time, it provides visual and CV feedback.
The big picture: you feed the module information about the rhythm, which is stable. The module runs the rhythm game, and scores the player’s performance. The performance becomes a source of modulation, to be fed back into the rack, altering its sound.
There are many ways stepcharts could be generated, but what’s important is that they have to be generated a few bars in advance to give the player enough time to see which step they’re expected to hit.
By using delays, generating them in real-time would work, but the rack would no longer be real-time!
To make it work, the module needs some smart heuristics, and also knowledge of the rules of the game. Those rules are generally obvious to anyone who played the game - for example, humans generally have two feet or fewer, so hitting three arrows at once requires bending over and using your hands, which dramatically increases the difficulty of a stepchart.
There is a lot of prior art for generating DWI (Dance With Intensity / Stepmania) format stepcharts from audio, but those algorithms are not expected to run in real-time. There is also a large wealth of freely available DWI files, that could be mined for patterns, like Grids does it for drum patterns.
The easy way out, obviously, would be to just load existing DWI files. It’d work too. Just not as cool!
Such a module would be, obviously, best used as part of a public installation, with a high quality metal dance pad or cabinet, where the DJ operates the rack, and members of the audience are invited to play. The audio feedback from the performance should be dramatic to make the performance truly interactive.
Yeah, such an idea would probably only ever be implemented by someone who hopes to run such an event. Send me the video of it if you’re crazy enough to do it!
5 Likes
That would be great, I really would like to try it.
maybe you can send me a beta and I will test it.
Electronic Components Plugin
A set of modules which simulate the behavior of basic electronics components like:
- resistors
- capacitors
- inductors
- transistors
- LEDs
I started thinking about this about a year ago, but I got stuck on a few points:
- I think that each module would need at least 2 inputs. One for voltage, and one for current. Perhaps this could be handled via polyphonic cables.
- Is it feasible to simulate the behavior of individual electronics components without considering the circuit they are a part of?
- In VCV Rack modules, the inputs and outputs of a module are necessarily separated. Electronics components do not have this built in directionality. Is this a problem?
It would be cool to wire up an RC filter using components of the proper value and have it behave like its real-world counterpart. Obviously it would be way easier to just use an existing filter that a developer spent time perfecting, but for me half the fun of all this is toying around and seeing what kind of bizarre things people come up with 
2 Likes
Wouldn’t work because electrical components are not black boxes with buffered inputs/output. You could however write a UI for building a schematic and solve it in real-time. It won’t be easy for both the UI and simulation.
2 Likes
Yep sounds about what I meant!
Snapshot Module
(Pretty much a copy of the snapshot module in Native Instruments Reaktor)
A module that capable of creating and recalling snapshots of parameters in a patch.
This module would need to somehow be aware of every knob/button/slider/etc in a patch. Alternatively it would either work as an expander to something like VCV MIDI-MAP or Stoermelder’s MIDI-CAT and only reference mapped modules. Another alternative would be allowing the user to map parameters from the Snapshot Module and only those parameters be affected by the module.
Say you’ve built a patch and you are tweaking knobs. Every time you discover an interesting sound, create a snapshot. Want to go back to that interesting sound you created earlier? Recall the snapshot. Of course you can keep saving a new version of the patch, but there is loading time when opening patches. Also this cannot be done via CV.
Snapshots would be stored in banks, thus allowing you to create banks based on type of sound (bass/lead/etc). Snapshots can be placed in Morph Bank A or B and allow morphing between the two.
The module would consist of the following:
- Displays:
- Bank (displays the bank currently selected by the Bank knob or CV input)
- Snapshot (displays the snapshot currently selected by the Snapshot knob or CV input)
- Knobs
- Bank Selector (selects which bank to store or recall the snapshot in/from)
- Snapshot Selector (selects which slot in the bank the snapshot is stored in or recalled from)
- Morph (morphs between snapshots in Morph Bank A and B)
- Buttons
- Store (Stores the current parameter values in the snapshot selected with Bank/Snapshot knobs)
- Recall (Recalls the snapshot currently selected with Bank/Snapshot knobs)
- Load A (loads the currently selected snapshot into Morph Bank A)
- Load B (loads the currently selected snapshot into Morph Bank B)
- Toggles
- AutoRecall (if turned on ignores the recall button, and snapshots are recalled as soon as the Snapshot or Bank knob is turned)
- Next (if turned on the Store button or Store CV input will store a snapshot in the next slot) This allows you to quickly build up a bunch of snapshots with a single button whenever you have an interesting sound)
- Inputs
- Bank (selects bank)
- Snapshot (selects snapshot)
- Store (stores snapshot in slot based on the value of Bank and Snapshot CV ins or knobs)
- Recall (recalls the snapshot in slot based on the value of Bank and Snapshot CV ins or knobs)
- Morph (morphs between snapshots in Morph Bank A and B)
- Outputs
- Trig (sends a trigger when a snapshot has been recalled - good for resetting sequencers etc.)
- A (loads the currently selected snapshot into Morph Bank A)
- B (loads the currently selected snapshot into Morph Bank B)
- Right Click Menu
- Export Bank (exports bank with all included snapshots to a file)
- Export Snapshot (exports a single snapshot to a file)
- Import Bank (imports bank from file)
- Import Snapshot (imports snapshot from file)
Not a module but I have a program in beta which does something like this.
Feel free to DM me for beta access.
2 Likes
awesome sauce.
As for further ideas: https://www.perfectcircuit.com/signal/microsound
- amplitude envelopes
- duration
- shape (see “figure 3.2” cribbed from Microsound)
- pitch envelopes (as in glisson synthesis)
- grains that start at the same pitch and go out randomly
- grains that start randomly and end at the same pitch
- grains made of different things
- 2-op FM
- simple subtractive synth voice
- filtered noise
- for extra points, make a granulator with every Braids mode randomized per grain
- grains going to different outputs
- stereo spatialization (Haas effect?)
- vector panning so users can have different outputs go to, e.g. different reverbs or different filters
- Abstract polyphonic grain master
- instead of having a module that makes sounds, make a module creates polyphonic CV signals to control grains (just an envelope and a gate would do), so the user decides what’s in the grain.
So I’m sure you’ve have all that done by next week.
@George_Locke oh yeah, I love these ideas!I thought about grains made of portions of bytebeat questions. The pitch envelopes sound especially interesting. I also love the grain output ideas. I’m probably going to be making Ghosts and Goblins stereo. I think building a brand new module that includes your suggestions is now on my to-do list!
^ I know, right? I really need to get outside a bit and do some fishing! Module programming has been all consuming lately.
2 Likes
Are you aware of my 8FACE module? It does some of what you describe for one module but many of the things of Snapshot Module are not feasible within Rack, at least in v1.
Especially morphing won’t work as you expect. Also, most of the modules have an internal state besides knobs/buttons/faders etc. which needs to be stored and recalled. This isn’t something that can be triggered by CV (even my module does not work as reliable as I like it to).
2 Likes
@stoermelder Yes I’m aware of the 8Face,and all your other modules, which are great! In fact, it’s seeing your modules that made me think at least some of the ideas in Snapshot Module would be possible in VCV Rack.
Forgive my ignorance/lack of knowledge, but would you know/be able to explain which parts are feasible/not feasible? I’d be really interested to know what the limitations are.
When you say internal state, do you mean parameters that are controlled by other means (say right click menus)?
Say if the functionality was limited to just being able to have a module that stored/recaled snapshots of the state of parameters mapped in MIDI-CAT for example - would that be technically possible?
I’d also be interested in knowing how morphing wouldn’t work as expected. In my mind the only thing that would change when morphing would be say knobs going from -2 to +4. Obviously any parameters that are either on or off would not morph smoothly (just jump between their state when the value is above a certain point).
There are obviously many other limitations in this idea, such as what happens when you’ve added modules/mappings since the snapshot was stored - in which case they would just be ignored. Also, not being able to store cable connections and considerations for what happens if you add modules to your patch (in my mind they would just be ignored).
A quick answer on this: yes, this is absolutely possible. Actually I added an idea for later to my GitHub repository a few minutes ago as I’m too busy to work on any modules at the moment.
1 Like
Interesting! I’ll keep my eyes open in case something comes to life! Wish I had some programming skills so I could work on something like this myself.
linear algebra I’m working on this one.
Would it benefit from having save and load options, to save the (256) matrix coefficients of a particular transform?
1 Like
Actually @pyer and I have picked this idea up, but it’ll be interesting to see what differences we come up with!
4 Likes
Densifier
- 16 GATE outputs
- TRIGGER input
- DENSITY knob
- CHANGE RATE knob
- AVAILABLE GATES knob
GATE OUTPUTS may be
- high
- low
- disabled (determined by AVAILABLE GATES)
DENSITY controls the number of GATES that are high at any given moment.
On each TRIGGER, the module randomly selects n low GATES to turn high and n high GATES to turn low, where n is determined by CHANGE RATE.
1 Like