first: as you renamed the module and svg I had both the prototype and the new update in my library,
and it didn’t load the update first, but I changed that and can now use both.
I see all popups on the modulation cv inputs show “clock input”, beside the real clock input,
I miss the mix output as I used it in a patch and liked the output of it, I would have liked an attenuverter with cv in for the mix output to modulate it, but maybe this can be in an update or or an expander?
the prests saved with the prototype won’t load in the updated version, but crash VCV as the update has another module name in the presets.
So maybe you should advise everyone to first delete the prototype before testing the update, or be aware of the changes.
And I still like this module very much!!!
I would keep the clock input as “clock” ( many other modules have it like this) and maybe change the length knob to lenght/sync.
Oh, interesting, I’ll have to figure out what’s going on with those crashes, I didn’t have any problem with the two modules sitting side by side.
Thanks for the feedback!
If I really squeeze everything in, I could add the mix out, but I feel like it would make the module a lot tighter and maybe too busy. For now I think it’s best to use an external mixer, and that gives you the freedom to have them in stereo or mono.
Although if lots of people want it, I could be convinced to come up with something.
It’s true that three fonts in a design is often quoted as a good place to draw the line. You’ve got the module name, the labels and the logo. It’s fine. Tell them I said it’s ok.
Now the Length knob functions as a sync select in much the same way as chronoblob’s when there’s a clock input. Clockwise increases the length multiplier by 2-6, and counter-clockwise, it divides the length by 2-6. With 1 being in the dead center.
If there are no bugs that crop up while testing, I’ll submit this one to the library.
Also, this time I remembered to update to the latest SDK 2.3.0 for all three builds (linux, mac, win), so hopefully that will get rid of any compatibility issues.
Ah! And I just remembered to go fix those mislabeled inputs, thanks again @rsmus7!
Code cleaned up a bit, I chose the mit license and made the code freely available, and submitted it to library tonight.
There’s a lot about optimizing for modern processors that I have yet to learn, but this stays around the 0.3% cpu usage of other simple modules, so hopefully it’s a decent example for other aspiring reverse delay programmers to pull from if they could use a starting point for their own work.
I also used the ‘hidden’ option for Taps_Proto, so – if it works as intended – then whenever it makes it to the library it shouldn’t break any patches that used that pre-release module. But also hopefully nobody except beta-testers will have to see my ugly first face plate
Documentation is still yet to be written, but this weekend I’ll work on the README file.
Code is here:
Oh dear, and I still need to add .ds_store and such to the .gitignore.
Great work Dan!! People like you, willing to be creative and share the results makes this a vibrant and interesting community. Taps is already a personal fave! I like focused modules that do one thing well, and this is a great example, superb work. I even like the original artwork, it was charming and made it easy to understand. I have one feature request that would take this over the top for me. A trigger input that would empty the delay buffer. When I use this as part of the sound design of a melodic or harmonic part, I need a way to drop old chord tones for new ones, and dumping the buffer at the start of each new chord seems the easiest way. No problem if this will not make it into the module, I appreciate your kind generous work nonetheless.
Any idea when the new version will be in the library? Really looking forward to trying the new features/inputs and seeing what wonders these perform. Thank you for making these wonderful versions, btw will the new one overwrite the old one?
It’s been released finally! I think it will update smoothly, but let me know if you have any issues.
I just finished the last touches on an album tonight that I’d been working on mastering since I finished this module release. So now I should have some time again, I think my next project will be working on the clear-buffer idea that @cubistguitar requested. I hope to have a version with that this month.
Anyway, red-letter day for me, finishing an album I didn’t think would come together, and seeing my first module go public. Thanks for all the feedback from everyone in the thread! It helped a lot.
Congratulation on the release, and thank you, it will be used a lot on this side of the screen !
It is awesome with audio but it is BRILLIANT with CV, send an ADSR, and watch it do its thing, the result is really musical !!
Edit :
As a wave shaping tool for LFOs, brilliant again :
Using the version in the library… If I change the delay tap with the knob it briefly sounds terrible. Also, if I modulate the reverse tap with a slow LFO I hear all kinds or bad high frequency stuff. In the illo below, the bottom FFT trace is my sinewave input, the top is what is coming out of the reverse output:
Thanks Squinky, I looked at a number of delay examples and didn’t see anybody worrying about aliasing in their code, so I got a bit complacent, I should have put it on a spectrum analyzer. Still learning best practices.
I’m rereading your article on aliasing now, but if you have any specific recommendations let me know.
The code is a little messy in parts, the actual change to the buffer index that is being controlled by that mod input happens on line 302, but I wonder if maybe an antialias filter when the samples are retrieved from the buffer might do the trick.
My plan is to filter at the nyquist frequency before the sample gets added into the feedback loop, but this is my first time working on a module, so if you see any pitfalls with that plan let me know.
Do you have any recommendations for an efficient filter for such an approach?
TanaBarbier, I added this suggestion to github page with attribution, hopefully that’s okay! And noting Squinky’s bug, you might want to filter the output for now when modifying the Distance parameters.
I don’t know that this is aliasing?seems unique to the rev, the fwd doesn’t do it. Not sure what’s up. I expected to find interpolation noise whe the delay time is modulated, but that didn’t seem to happen…
