Where is the best place to report bugs or ask questions about v1.0? The fact that the module browser is so limited and crashy makes it tricky to port plugins to 1.0. I figure at this point you probably know about enough bugs that they aren’t worth reporting yet?
I don’t need testers for the v1 branch yet. I will make an announcement when it is ready.
I would like to take v1 offline to prevent people from wasting time on it. However, some people would like v1 to be online to inspect the code on their own time. Suggestions?
Good question. Probably leave the branch up, but continue to tell people is isn’t ready is what I would do? btw: I have one module just about ported - it loads and seems happy.
Okay, I will continue to say that it isn’t ready to those who make comments about it.
it sounds FUN
I’ll try to keep my v1 branch working in v1, so if you need any test modules…
Maybe name the branch something other than v1. Use a name that indicates its state of development.
But you’ve gotten yourself into a situation where people are champing at the bit for whatever comes next, so branch names will help only so much. The price of success!
@Vortico I read of your intention for an express announcement with regard to v.1.0. One curiosity. There will supposedly be a “transition” phase to v1.0, like it happened for v0.6, with Review/Library teams or the need for community support? Currently, I’m simply following the Plugin API Updates Thread. There will be other reference points?
EDIT: nice, I see have already part of the answer by reading your new topic: Guide for migrating 0.6 plugins to Rack v1
You’ve referenced the wrong username. The Rack v1 API will be called stable, and Rack 1.0 will be released a few weeks later.
Ops, sorry for mismatching the name, I didn’t notice, the alias “@Blamsoft” got me wrong. I have just edited the post to correct it. Anyway, thanks for the answer!
Is the mouse handling and other aspects of 1.0 API close to what they will be? I’m happy to port that stuff over, but only if it’s not expected to change “too much”.
The event system is pretty stable right now. The only other change I might do is give
DragHover, etc a
button field so right-click and middle-click dragging can be supported. But I’m debating that one.
If anyone wants to push event stability faster, give https://github.com/VCVRack/Rack/blob/v1/include/event.hpp and https://github.com/VCVRack/Rack/blob/v1/include/widgets/Widget.hpp a very close review, imagining all possible situations plugins may need.
I put up an enhancement request in the github issues. For reasons even I can’t justify, I use the MS compiler to build and debug my unit test suite, and I can’t quite get it to work with 1.0. I think a nice safe “one liner” would git me over the hump: https://github.com/VCVRack/Rack/issues/1173
I noticed the MinBLEP support is refactored. To port stuff that worked with the old classes, I’m guessing to templatize on <16, 2>? figure two zero crossings is all that EvenVCO needed - If I’m guessing correctly what that parameter means.
It also looks like the port isn’t done? the hpp file references
void minBlepImpulse(int z, int o, float *output);, but I don’t see that implemented in any cpp files.
MinBLEP is finished and implemented in
src/dsp/minblep.cpp. EvenVCO uses 16 zero-crossings with 32x oversampling.