As usual, I don’t understand your comments. In any case, I’d like to think that @trickyflemming are on reasonably friendly terms.
As it happens, I like writing unit tests, so I wrote hundreds or thousands of them for my old modules. Other ppl maybe don’t like doing that, so they don’t - that’s fine.
I will confess it was a mild dig - I always write tests that polyphony works like I want it to, so there is probably and zero percent chance of making that particular mistake with a simple test. But there are plenty of ways to make reliable software, all of them are fine.
I can understand the need, but I also don’t write unit tests unless it is a necessity of the job description. I prefer a good old hard fail, and not even an assert or helper null handling behaviour (as that doesn’t catch all). Debuggers are fine for some things but for real-time the breakpoint concept is inadequate as timing can be delayed into an alternate error point.
If a unit test is required, then it is often a mistake to compile it out of the release code, as the test itself has some merit as a timed proof of work entropy source. Even users should be able to test suite a thing if possible.
EDIT: On trigger, or if menu enabled set outs to zero, perform incremental small amounts of unit tests and when complete set output entropy 10V and resume regular processing?
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.
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.
Open source and compilation of an architecture independent OS specific source?
Surprisingly 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.
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.
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.
