I am glad I’m not the only one!
And I thought it was just me…
yeah, like I said, when you program by yourself you can do whatever you please, and that’s really a positive.
I started writing tests at a previous job where there were very few tests, and they weren’t required. Mostly as joke I started doing TDD, but discovered it really worked for me. That particular thing didn’t ship while I was at the company, but several years later they resurrected it, and were pleased to find all the tests. And the software still worked and had no bugs.
But that was more than a decade ago. Now I think almost all software projects have and required a good number of unit tests.
Long ago (long ago!) I found that I couldn’t make reliable DSP code without unit tests. Silly bugs like getting the cutoff of a filter wrong (by a factor of two pi or worse), mixing up byte order in vectors of audio, too much noise in basic filter building blocks, thread tear-down that deadlocked, etc…
I’m sure other’s have ways of avoiding these pitfalls. It’s not about the programming process, but about the end result.
would it be possible to add polyphonic capability to the SCANNER module? if so, 5 channels is the amount i desire.
welcome to the club! …
So you two also got nothing on this thread then?
That one sets a record. I have no idea what it is.
Another vote for this.
I hate to say it, but I do not understand anything from this person. That worries me because my plugin is mentioned in projects that I do not understand the legitimacy of.
That project I do understand. He is porting or re-compiling VCV Rack and the plugin build system to be Chromebook native. That kind of cool since chromebooks are pretty cheap and pervasive. At least among students in K-12.
But how would that ever work unless VCV adopted this port?
Open source and compilation of an architecture independent OS specific source?
lin-arm64 can be quite general. The Chromebook specific is based around hardware detection in
libsamplerate-1.9 being quite old from the Chromebook ID that it can supply. The main reason
mac-arm64 can proceed faster is the decision of the most efficient architecture is by design. In generic arm Linux land older arm7 or insist on
arm8-a at least for a library? Maybe even an
arm8-m? It’s not as though the build farm can’t exceed my machine, and I have been a
./configure aware person since at least '95.
Started work on a simple, clear, and polyphonic gate delay (available now in the nightly build). I’m thinking about adding in a second gate input that is ORd with the current input. That way it’s easier to setup delayed gate cascades as loops.
I’ll look into it! It would be 16 channels like the rest.
would it be possible to make the gate delay syncable to bpm/quaters/eigth…?
Yes, I’m considering whether I want to do two modules or just one big one. The tough part is finding time to work on all the things I want to make
Other general port ideas:
- A gate output that is high during the delay stage.
- A gate output that is high when the delayed gate is finished.
- A gate input to reset everything (killing the current output gate if high and canceling any pending delay)
- A trigger output that combines the input trigger and the output gate as another trigger.
- The current code uses VCV’s Timer class, while my Reaktor Euro Reakt version used a phasor for the delay. The Euro Reakt version outputs a phasor with the current delay phase. Could be interesting.
still possible feature in the future? (poly scanner)
Yep, just way behind on projects at the moment. I have a polyphonic batch of Unfiltered Volume 1 modules (along with port and label updates), so I’m finishing those up first.
Oh joyous day
BTW I’m happy having these very useful features in the Hetrick plugin!
It could probably fit into 6-8. I like to keep things slightly wider… and I also like to reuse existing SVGs and layouts to save time