as an example:
Saw that same video, it was bonkers!
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
thanks for the patch, love it !
and nice impro btw
So, I’ve been working on this…
@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
I like it, or at least as I understand it.
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.
I look forward to seeing where you go.
@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.
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.
Thanks! No worries! Just noticed a bit of a downsampled sound when changing pitch to non-octave intervals.
I thought Simpliciter couldn’t change speed during recording or record backwards… have to check that out again.
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?
ah yes, only while recording forward and changing speed, but quite harsh.
This is a bug and I’m actually fixing it.
@Schabbes The bug is no fixed in version 2.1.7 and distributed in the official VCV library.
After a month or two of hacking at it, the first version of the BASICally module is now in the library. Documentation here.
Tried it and it works fine for me. Is there a limit to how many lines I can have? In testing, I was allowed to go off the bottom of the module window, but I see no obvious way to scroll. Can I scroll?
Fuller announcement here.
I have working code that scrolls, but it won’t be live until the next version.
My ugly suggestion as a current workaround is to make the module really wide. See the resizing bar on the right side.