As near as I can tell, there’s no VCV Rack module for people to type in simple “output a value, then wait” commands and have them run. That doesn’t surprise me; it’s not something you see in the hardware world, and I’m realizing that I’ll need to make the language quite narrow to keep the module sufficiently performant. But being able to put just a bit of code in Rack feels like a very useful ability, so I’ll likely take it on for my own amusement.
(Side note: while this “user code → signals” idea seems heretically contrary to the whole modular mindset, it reminds me of a ceramicist acquaintance who struggled mightily to get a glaze that would do the right shade of red on a piece of clay. Eventually he just spray painted it the desired color and was done with it.)
I am surprised, however, that I’m failing to find a tape/sampler module that can act like the one in the video. I think of it as having the ability to:
always add to existing sound under the tape head
and can record in reverse
I’ve tried Complex Simpler, ahornberg’s Tape Recorder, Jira Jira Echo, and Simpliciter Multi. I could easily be missing something (these are not all thoroughly documented modules). Are there ways of using these I’ve missed? Are there candidates I should be looking at that might do the trick? I was hoping to avoid writing the tape part, but will if it would fill a niche.
For typing out control messages, I’m not sure if it’s what you’re after, but there is a port of Monome Teletype in the library somewhere (search appears to be borked ATM, a search for teletype returns 425 modules, but I’m pretty sure it’s in there somewhere if that’s something that interests you).
@disquiet had mentioned this Teletype implementation to me as well. While the language looks so terse (understandably, given the original hardware UI) that it’s giving me FORTH flashbacks, I should at least attempt to get myself past that and try it. Thanks.
there is a tape module that comes with the Nysthi Simpliciter sampler, can do sound on sound and via the Tape expander can be run in reverse and such, world’s your oyster. Should get you at least close to that territory
Building a DSL for this would be a fun and interesting adventure! But in general, this also seems like a good use case for VCV Prototype (although it’s not in V2 yet for some reason, apparently it’s not hard to patch over: scripts in VCV (prototype missing in v2 ?) - #7 by steffen.plunder)…
I like (and relate to!) your ceramicist story, BTW
@robb: “teletype” is interesting, but seems to be tuned to running tiny programs based on triggers. I’m thinking more of a sequencer/signal modifier.
@fractalgee & @Ahornberg: I was able to get Simpliciter Multi to do some variant of the behavior that I think is going on in the video, though not quite the same. But I’ll have to watch it again to really sus out what that recorder does. But I have gotten results I kinda like, using field recordings as input instead of simple tones as in Hainbach’s video.
It did finally occur to me that the code part in that video could really be done by any number of sequencers. That said, @gc3 is correct; the Domain Specific Language idea proved too tempting to not work on. While still very early stages, here’s a screen shot of what I have working today:
NB: That UI is super early, and I anticipate having IN1-4 and OUT1-4 (as well as some other controls on the behavior). And there’s more to add to the language besides assignments and WAIT statements. But it runs. It even compiles as you type, so I’ve also made a terrible live-coding language
One thing you might consider for doing this in a way totally different from most, if not all, VCV Rack sequencers is to write a discrete event scheduler and handler. All previous incarnations of my Meander module were based on discrete event handling. I did one in Javascript within MAX/MSP within Ableton Live in about 2017. I developed my techniques while doing discrete event simulations for semiconductor wafer fabrication plants where every product, process, process flow and process machine is modeled and time flow simulated. Whereas a sequencer usually operates at DSP process() speeds, a discrete event scheduler and handler only does work when the time arrives for the most imminent event. Handling an event results in scheduling next events.
Anyway, something to perhaps consider. Of course though, I have not ever done such that also does sample playback scheduling which has to take place in the DSP process() look, so I have no idea what all might be involved. And, I have probably totally misunderstood where you are going with this.
@k-chaffin, are you suggesting that for the sake of CPU efficiency? So far, at least, it’s not taking up a lot of CPU (e.g., on my laptop, it’s using less than Scope). Or is there some other reason you suggest this?
If you squint, what this is doing is pretty close to what you suggest. WAIT statements take relatively few cycles per process() call. But I could take that principle further, now that I think on it…
On the other hand, one intention for this module is as a way to quickly try out transformations on signals that are more easily understood (at least by some) as mathematical expressions. And it seems to do that ok as well. That said, it’s not as CPU efficient to run, say, out1 := in1 * in1 as using the Little Utils Multiply/Divide module is. But it might be faster to try it this way? So BASICally may find some value in prototyping a signal transformation before a user hunts down a more efficient way to do it, if they find they need to.
My main motivation, I think, is to allow another paradigm to exist within VCV. There are certainly better systems for doing ALL of sound generation as procedural math. But this will allow a bit of procedural math into the paradigms that VCV excels at.
It was the “wait” statements that spurred me to suggest discrete event scheduling and processing. I was thnking of this for CV manipulation, but it can work for audio also. Basically in involves using event objects and some type of list event queue where when the event is scheduled it is inserted into the event queue with most imminent event time at the head of the list. In such an event processor, one just has to check whether the system time is equal to or later than the event time at the head of the queue and only handle it if it is. That event has to be removed from the queue if it is handled and new events scheduled if appropriate.
Don’t worry too much about this suggestion. I’m sure I’m not fully seeing where you are going with this. A Discrete Event Simulation (DES) can be pretty complex. Meander for Windows had its own event object memory manager and used linked pointer lists for just about everything. The Max/MSP implementation used Javascript “lists”.
Have you played around with the Submarine “Arithmetic Operatosr” (AO) series modules for mathematical event handling?
Your Tape Recorder works really great for this! I played around a bit with a constant sine and connecting a MIDI keyboard to the speed input, playing a few notes while recording, running it back and forth, and was really happy with the results.
It does seem to produce some aliasing when pitched, though. Maybe you could put some interpolation on it?
The Lomas sampler has a few options for interpolation, which all seem fine and are open source, maybe one of them could help with a smoother sound.
Actually, Tape Recorder uses linear inperpolation. Maybe better interpolation will be implemented in the future.
If you want more audio quality now, feel free to use Simpliciter and SimplerTapeControl by NYSTHI. These two modules also do a good job on simulating reels.
In theory (not that I’ve done it), you not only have to do good interpolation, but if you shift a signal up to a freq where it has components above nyquist you need to filter those out, too, before they get re-sampled
and turn into aliasing.
I think we have to assume that “wait x” doesn’t turn into “sleep x”, but turns into “start a sample counter and don’t advance the virtual program counter until that counter expires”. the first would be terrible, the second would be fine.
For sure. A discrete event scheduler and handler is just a fancy wait, but isn’t too useful for DSP sound processing. It can be great for “sequencing” though.
And, that sequencing could be DSP algorithm state changes, I.E., state changes that affect the per sample DSP code, but do not change at anywhere near per sample processing speeds.
@Schabbes Just for verification: Do you mean a harsh and noticeable aliasing that only occours on changing speed while recording in forward direction only?
