Do you think with this it would be possible to send CV signals from computer to computer via an audio channel?
You can do that with OSC over local network with the trowasoft module as well.
Interesting idea… Using a digital connection like ADAT or S/PDIF this should be possible…
Using an audio connection for something like CV give you a sample accurate signal (besides a constant audio driver buffer).
I’ve removed a few posts in this thread. If I’ve removed yours, re-read the thread rules.
I think it all depends on the audio interface. Some DAC audio interfaces are “CV Ready”, be careful with their specific characteristics in terms of voltage and amperage. personally on an almost similar context to control an old CV synthesizer via an audio port, I had to go through an old mixer to amplify the signal with all the problems it adds but it works not to bad. Otherwise you have the good old soldering iron, an oscilloscope to convert your signal in order to satisfy the input of your card according to the output sent …
Expander-based sequencer pipeline
So, this is something I might (maybe, possibly, some day, idk lol) eventually work on, but the idea is still very half-baked and I have not really verified the feasibility of the implementation, so I’m posting it in part to gather feedback. If you adopt this idea, please let me know (in private or public).
The idea is to let the user craft their own generic sequencer system by assembling together small tools that do one thing well - the Unix philosophy, kinda. It could be used to program gates, triggers, CV, pitches, chords… all sorts of things.
The system would be based on expanders, forwarding a data structure to be processed as a pipeline, requiring minimal boilerplate cabling.
It’s unapologetically an idea that only makes sense in the software world, and it does not enable previously impossible workflows - it merely makes them more user-friendly.
It would make more sense with examples:
The UI would be generally comprised of a sequencer, followed by an optional bank switcher / song programmer, the clock input, feature enablers/programmers, and various output modes.
When you add a feature enabler, e.g. the octave up and down in my last example imitating a 303, it sends a message backwards to the sequencer to enable this feature, so instead of the step sequencer being comprised of toggles, it becomes comprised of buttons with 4 possible states (Off, On, Octave up, Octave down).
The implementation would be different than the UI! For example it probably makes more sense to store each pattern bank on the sequencer, but only expose them if the user adds a bank switcher.
Not every part of the system could be piped together to form a coherent system, so there would be little indicators whether the pipeline is working, like I do on my Arcane system:
The whole system is heavily inspired by my own way of using and abusing Kompulsion in the Reason environment, but with a very different UI metaphor.
Once again, I stress that this idea is 100% about UI, 0% about things you can’t already do in VCV.
So I ended using two “PART” modules (thank you for the module!) and set the low and high notes using the split knob.
And a “BOOL”, which takes the “high” gate from the 1st PART and the “low” gate from the 2nd PART and sends the AND condition out.
Both V/Oct and Gate feeding the “PART” modules come from a single MIDI-CV
Like this.
This example only allows for note “G1#” to send a gate.
You don’t need boolean logic. You just use the first Impromptu Part to filter out everything below G# and then a second Part to filter out everything above G#. The result is a gate which is only triggered when G# is played (for each polyphonic channel).
Do you have an example? Somehow I always ended with one end of the keyboard sending gates, not only a region. Or should I connect both Low and High to the Gate receiver? (ADSR)
Thank you that worked wonderfully.
Nice! With four instances I could also make a piano VST to play on two regions to effectively limit the high end and avoid playing over a single note on the low range.
This method has added a lot of flexibility
so as much as i enjoy rack i think it could use more lofi modules. its often very polished and clean sounding which is awesome but i think it would be nice to be able to experiment with more lofi processing not just bit crushers. what i had in mind is something that sounds like the vinyl simulation algorithm on the original roland sp404. another example would be digdugdiy’s “purple rain” which aims to achieve a similar result.
MFX14/MFX16 (either or)
knob and cv inputs for pitch(“rpm”) and level.
lofi compression 8bit and 12bit switchable with ducking effect.
“dust” knob to increase or decrease crackle and hiss.
wow and flutter “warp” cv modulation input.
“degrade” (distortion/filter?) knob to simulate worn out vinyl.
input to process audio but could also be used stand alone as a noise source.
hopefully there are others who share some interest in something like this. im so bored here as the state im in has issued a mandatory stay at home. boredom is probably getting the best of me.
Nysthi jira jira echo Hetrick crackle and dust
thanks for the suggestion. still very clean and sure it’d be possible to patch in the bit reduction, filtering, compression ect but im still not sure it would achieve the same crunchyness the sp404 algorithm has, plus that would use up more cpu. it would be nice to have a single module to do the dirty work so to speak.
A Glide/Legato utility module
A module that implements legato (like the Vult Vessek oscillator does).
Inputs for pitch and gate and a switch to apply the glide only when a gate is skipped.
A knob for the glide length with modulation input (and optional attenuverter).
And a switch to switch between constant glide time and constant glide rate.
Optionally a second knob to fade between logarithmic - linear - exponential glide curve.
Output for the slewed pitch.
Also have you tried Sangster by Lindberg?
I’ve got a keyboard splitter working. It’s only monophonic, adding polyphony as next step. Peek preview at: https://github.com/JoakimLindbom/JLmod#KeySplit
I think @marc_boule’s implementation is more elegant because you don’t need separate CV outputs. With polyphony, they’re simply copies of the input CV, so you can just use that signal directly.
Ah, Ididn’t see it until now. The module don’t need separate CV output, they’re optional. And the module from @marc_boule looks nicer…