Sending a bit of encouragement - just remember, when people argue about your things it’s because they care, which is better than nobody caring
If it gets you down conforming to other people’s preferences, you can always change back!
But good luck with the home stretch, those final bits are always the hardest hardest, because all the fun stuff has been done. I have so many tracks that I really like which never got that last 1-5 percent of work that would have let me be really proud of them.
But the modules look really great, I hope you finish!
You are one of the most consistently helpful folks in the community, Dave. I’m sure that if you asked, there would be plenty of people willing to put their time & talents into some demo patches or videos for these cool modules.
Thanks all for your words of encouragement!
@LarsBjerregaard - I am not down at all about switching to Ivory as the default - I am perfectly happy with that decision, it just took me a while to get there.
@demcanulty nailed my feelings perfectly - the home stretch looks daunting, and energy levels are flagging. This will be released, it is just a question of how many of those last tasks I mentioned will get done. The demos and examples could always be added later, but I think they will not have as much impact as if it all gets released at once.
@augment - I have been thinking of reaching out to see if certain folk would like to create demo videos. I think you pushed me over the edge to actually do the right thing and reach out.
If anyone has some interesting patches featuring these modules - I would love to see them. It would be great to see how people might use them when they are released. And if it really focuses on the module and demonstrates a good use case, I will likely include a link in the documentation.
I just realized I need to change how Bernoulli Switch polyphony works. Currently every channel on polyphonic inputs always get their own coin flip, so polyphonic inputs get “mangled”. I think this is an important feature, but I also need to support the simpler case where all the channels remain together, so there would only be one coin flip for the whole.
I can’t wait to try out your modules Dave. The 2 input 2 output Bernoulli switch in particular is something I’ve needed for a while now. But really looking forward to the others as well. Great work.
Thanks! Yes, I have been dreaming about this one for a long time as well.
I think it would also work especially well in hardware, though maybe expanded in size a bit to make it easier to manipulate. The more I explore it, the more uses I find - it is incredibly versatile and I think perfect for a fixed rack. But among its many uses, it also solves some niche use cases that are not covered by any one existing VCV rack module.
Venom Beta 3 binaries and updated documentation are now available at the same GitHub page: VenomModules/README.md at main · DaveBenham/VenomModules · GitHub
Ivory is now the default theme. But the main reason for a new beta version is the significant change in how Bernoulli Switch handles polyphony. The old version always scrambled polyphonic inputs with a coin toss for each input channel. But now polyphonic inputs can be left in tact with a single coin toss. From the updated documentation:
Beautiful documentation Dave, exemplary! Thanks…
Beta 4 is now available at the same GitHub link. I’ve added two new modules to make it even more convenient to do recursive processing of polyphonic inputs. The Recurse modules handle the polyphonically recursive send and return of the inputs. The new Clone Merge and Poly Clone modules replicate CV without recursion to easily match the recursion. For example, it can be used to replicate filter cutoff CV to be used with recursive filtering.
Here is a demo patch and video using three different modules from my plugin:
Venom SwitchRecurse Demo Poly.vcv (4.8 KB)
I really am close to releasing. I’m putting down the pencil - no new modules or features. Just bug fixes if any are found.
It is your last chance to help me squash any remaining bugs. The Beta 4 release fixed the few that I found. Some of the modules are very deep, with many options and permutations, so there could easily be some more bugs lurking out there - waiting to be found.
Thanks all for any help.
This demo sounds so cool! I’m excited to see this plugin make its way into the library.
why not initiailze scale to silence that scary compiler warning - even it is just a spurious warning?
src/HQ.cpp:137:11: note: 'scale' was declared here 137 | float scale, pfloat=0.f, out=0.f, root; | ^~~~~ whey not just float scale =0;?
Hmmm. I don’t get a warning when I compile. I am not familiar with that warning - is it complaining about a variable not being initialized when declared?
most of your modules use a rectangle with rounded corners around the outputs, and it looks nice. Rhytthmn explorer doesn’t round the rectangles. Also the division beteen the last row of inputs and the first row of outputs looks too high.
yes. I’m building on windows - is that what you are using? Here’s the full context:
g++ -std=c++11 -Wsuggest-override -fPIC -I../../include -I../../dep/include -MMD -MP -g -O3 -funsafe-math-optimizations -fno-omit-frame-pointer -Wall -Wextra -Wno-unused-parameter -DARCH_X64 -march=nehalem -DARCH_WIN -D_USE_MATH_DEFINES -municode -c -o build/src/RhythmExplorer.cpp.o src/RhythmExplorer.cpp src/HQ.cpp: In member function 'virtual void HQ::process(const rack::engine::Module::ProcessArgs&)': src/HQ.cpp:195:61: warning: 'partial' may be used uninitialized [-Wmaybe-uninitialized] 195 | pfloat = inputs[CV_INPUT].getPolyVoltage(c) * scale + partial; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~ src/HQ.cpp:138:9: note: 'partial' was declared here 138 | int partial, pround=0; | ^~~~~~~ src/HQ.cpp:195:53: warning: 'scale' may be used uninitialized [-Wmaybe-uninitialized] 195 | pfloat = inputs[CV_INPUT].getPolyVoltage(c) * scale + partial; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ src/HQ.cpp:137:11: note: 'scale' was declared here 137 | float scale, pfloat=0.f, out=0.f, root; | ^~~~~
Probably not really an issue, but easy enough to shut it up
Yeah - I had some problems with the Rhythm Explorer fillets. I use Inkscape, and I was dragging the handle in the upper right like I normally do, and it had no effect. I revisited, and I guess there are two handles there - after moving the first, I then moved the second and it worked. Seems odd to me. I will publish with the cosmetic fix, but I’m not going to put out a new beta for it.
The gap at the bottom is intentional, serving two purposes:
- Make room for labels that require two text lines.
- Visually separate the bottom row from the matrix above. Note also that the bottom row ports do not align vertically with the columns above.
I don’t understand why you get a warning on Windows, and I don’t. I’m simply running make without any arguments, and all compiles without warnings. I did double check, and the variables are properly given values in the process code before they are used.
This is a total guess, but I have noticed that some C++ compilers emit different warnings depending on the optimization level. I have done debug builds with gcc/g++ using
-O0 that didn’t show a warning, but as soon as I enabled
-O3, the warning showed up. Not only that, the warning was useful, because it revealed I was accessing uninitialized memory!
I am building just by running make.
Here’s my compiler version:
$ g++ --version g++.exe (Rev9, Built by MSYS2 project) 12.2.0 Copyright (C) 2022 Free Software Foundation, Inc.
As I’ve said a few times before, I believe you that this is a spurious warning. If it were me, I would just add the unnecessary initialization to shut it up. You may do what you like, of course.
Just ran pacman to make sure my gcc is the current version. Seems to be.
looks good to me now.
gcc (Debian 10.2.1-6) 10.2.1 20210110
lin-arm64 only gives the SDK
Interesting. I’m running an older version:
$ g++ --version g++.exe (Rev8, Built by MSYS2 project) 11.2.0 Copyright (C) 2021 Free Software Foundation, Inc.
But the warnings are enabled.
The variable is only used toward the bottom in a conditional block only if “condition A” is true. Earlier in the code I have a conditional block “if A is true then set values”. If I insert a line that tries to use the variable before I set the value, I do indeed get the warning. So it seems like the compiler took a step backward in detecting uninitialized variables - over reporting unnecessary warnings. Did the standard become you should always initialize every variable upon declaration? - That seems like overkill to me.