vcvrack / befaco Goto Github PK

i find the cv inputs on the slew limiter kind of hard to work with as they only operate so well in a [0..1]V range.
is that intended behavior?
anyways, i scaled down the inputs on my local clone and it feels much more usable that way.

I don´t have the rampage but the serge DUSG. theCV inputs in rampage are inverted so sending a 1v/oct signal to the exp input it goes lower in frequency as you go up in the keyboard. Using an inverter in between as a workaround but I think the CV inputs must be reversed..

maybe related to VCVRack/Rack@5bc9a69

g++ -Wsuggest-override -std=c++11 -I./pffft -DPFFFT_SIMD_DISABLE -fPIC -I../../include -I../../dep/include -DSLUG=Befaco -DVERSION=0.6.0 -MMD -MP -g -O3 -march=nocona -ffast-math -fno-finite-math-only -Wall -Wextra -Wno-unused-parameter -DARCH_WIN -D_USE_MATH_DEFINES -c -o build/src/SpringReverb.cpp.o src/SpringReverb.cpp
src/SpringReverb.cpp: In member function 'void RealTimeConvolver::setKernel(const float*, size_t)':
src/SpringReverb.cpp:89:52: error: call of overloaded 'min(size_t&, size_t)' is ambiguous
    size_t len = min(blockSize, length - i*blockSize);
                                                    ^
In file included from ../../include/util/common.hpp:52:0,
                 from ../../include/rack.hpp:4,
                 from src/Befaco.hpp:1,
                 from src/SpringReverb.cpp:2:
../../include/util/math.hpp:21:12: note: candidate: int rack::min(int, int)
 inline int min(int a, int b) {
            ^~~
../../include/util/math.hpp:61:14: note: candidate: float rack::min(float, float)
 inline float min(float a, float b) {
              ^~~
make: *** [../../compile.mk:58: build/src/SpringReverb.cpp.o] Error 1

Should be:

		configParam(LEVEL2_PARAM, 0.0, 1.0, 0.0, "In 2 level", "%", 0, 100);

at line 17

When Rampage is set as follows the output rises to 9.451 volts then stops and the channel remains in the rise phase until the range is changed or the shape/rise time are reduced:

• Max rise time, fall time doesn’t matter
• Longest range
• Shape fully CW
• All other controls set to default values
• nothing connected to the input

To reproduce the issue, set a channel up as outlined above and manually trigger it.

Note that once the channel has stopped at 9.451 volts, adjusting the shape slightly allows the it to continue but, depending on the new shape setting, it stops again at a higher voltage. In the example below, the shape was adjusted to 0.9:

Issue discovered on Windows 10 and confirmed on Kubuntu Linux (here).

Hi all,

I'm quite excited by the Muxlicer addition; however, the menu option for "All in Normalled Value" doesn't appear to be changing when different voltage levels are selected. I'll probably take a look in the code when I have some time, but if anyone knows a quick fix, I'd be super appreciative!

When shape is left-most, we get noise in the outs. The issue wasn't present when the module was monophonic, and so maybe due to the SIMD porting. It appears to be connected to improper termination of the cycle, as there's a lot of activity on the rising/falling outputs.

Hi!

Thanks again for bringing this beautiful module to VCV! I have also the hardware and I noticed that the grit quantity knob is reversed so there are fewer grains to the right in VCV, while in hardware it's when turning it to the left.
Another thing I noticed is that in hardware, the filters will self oscillate at one point, but in VCV, they do not.

I'm not so sure if this is on purpose or not, but I thought I will let you know.
I'm sure you have enough to deal with now in your personal life (congrats once again!) so take your time with this.

Cheers!
Omri

It's debatable, but I think most ppl don't want a "audio frequency" pulse wave to be DC coupled.

From here.

What I did

1. Connect “Com I/O output” to “Gate mode CV input”
2. Turn “Gate mode knob” clockwise fully
3. Set the fader values as [0.1, 0, 0.2, 0, 0.3, 0, 0.4, 0] from left to right

I chose 0 at even-numbered steps, so I thought no gates would occur at it, but a short trigger occurred. I don’t have a hardware, so I can’t tell it is intended or not. I put an image which I hope to explain this situation.

I suspect that this is due to the there being a 1 sample delay being introduced by the patch cable. A possible solution is to introduce a 1 sample delay to the gate out generator, but more investigation needed.

@hemmer, I am not sure why this slipped through in the v1 review, but we should fix this for v2:

[Befaco] Issues found in `plugin.json`:
                                                                             
STMix: invalid module tags: Stereo
-- Valid tags are defined in https://raw.githubusercontent.com/VCVRack/Rack/v2/src/tag.cpp

Thanks.

OS: win7 64bit
Rack: dev

see attached screenshot:

rampage and the reverb too.

Is it intended behaviour that the output of the first A+B*C section only goes to 9.72 when no input is selected and C1 level is full right (or -9.72 when full left), while the second section goes from -10 to 10?

Cheers,
Martin

-10/0 Range has been removed from module, so it does not make sense (and even might mangle with the module) to have it in Bridge counterpart.

Stereo Strip, CPU shoots way up while dragging the EQ sliders

It seems sync is not working. Checked the code, looks like there is nothing done with this parameter.
Would be nice if it would work.

$ ag sync
src/EvenVCO.cpp
17:		SYNC_INPUT,
31:	/** The value of the last sync input */
32:	float sync = 0.0;
158:	addInput(createInput<PJ301MPort>(Vec(86, 189), module, EvenVCO::SYNC_INPUT));

Is it possible that the cycle gate input does not work as intended?

According to the manual, the inputs 18A/B should invert the setting of the switch.
In the plugin, they seem to override the switch, not inverting. Can anybody confirm?

Thanks,
Martin

Hello,
First of all thank you for the last update! I think that there might be a misbehaving in this module. When you brake the normalisation the second out doesn't work. You can see the led displaying the voltage but it doesn't t output anything.
Thank in advance

In case 'Filter TZFM DC' option is enabled, PonyVCO's output goes to 'nanV' while FM'ing at sample rates of 192 or 768 kHz.

To reproduce

• Rack Engine SR is to 192 or 768 kHz
• PonyVCO's 'Filter TZFM DC' option is enabled
• Feed some voltages to 'TZ FM'

Outcome

PonyVCO's output goes to nanV

There is no issue in case Rack operates at sample rates other than 192 or 768 kHz.

Rack Engine SR is to 48 kHz - ok
Rack Engine SR is set to 176.4 kHz - ok
Rack Engine SR is to 192 kHz - issue
Rack Engine SR is to 352.8 kHz - ok
...
Rack Engine SR is to 768 kHz or higher - issue

Win 10
PonyVCO 2.3.0
Rack Free Standalone 2.2.1

Seeing this with Rack v0.5, Befaco master:

➜  Befaco git:(master) make
g++ -I./pffft -DPFFFT_SIMD_DISABLE -fPIC -I../../include -I../../dep/include -DVERSION=0.5.0 -MMD -g -O3 -march=nocona -ffast-math -fno-finite-math-only -Wall -Wextra -Wno-unused-parameter -DARCH_LIN -Wsuggest-override -std=c++11 -c -o build/src/SpringReverb.cpp.o src/SpringReverb.cpp
src/SpringReverb.cpp: In member function ‘virtual void SpringReverb::step()’:
src/SpringReverb.cpp:219:13: error: ‘struct rack::SampleRateConverter<1>’ has no member named ‘setRates’; did you mean ‘setRatio’?
    inputSrc.setRates(engineGetSampleRate(), 48000);
             ^~~~~~~~
             setRatio
src/SpringReverb.cpp:231:14: error: ‘struct rack::SampleRateConverter<1>’ has no member named ‘setRates’; did you mean ‘setRatio’?
    outputSrc.setRates(48000, engineGetSampleRate());
              ^~~~~~~~
              setRatio
make: *** [../../compile.mk:54: build/src/SpringReverb.cpp.o] Error 1

I am on arch linux:

➜  Befaco git:(master) uname -a
Linux sorahan-desktop 4.14.4-1-ARCH #1 SMP PREEMPT Tue Dec 26 19:10:06 UTC 2017 x86_64 GNU/Linux

Issue to track the work still to do before releasing the first new batch of modules. Preview below:

Status

• Percall (90% done, just need to set/verify envelope times/shapes)
• Chopping Kinky (85% done, need to stress-test aliasing)
• Hexmix VCA (90% done, mainly verifying the shape against hardware)
• Kickall (60% done, wire in V/Oct correctly, wire in CV, calibrate with hardware)

Outstanding issues

• Calibrate and tune modules against hardware equivalents (and schematics)
  • Percall (envelope times)
  • Chopping Kinky (waveshaper response)
  • Hexmix VCA (shape response)
  • Kickall (tuning, CV summing logic, waveshaping, quite a bit!)
• Update graphics with SVGs from Befaco
• Check polyphony is implemented correctly
• Code cleanup/documentation
• Check performance is acceptable
• Check aliasing (Squinky Labs guide)
• Decide what to do about code re-use (currently using ChowDSP anti-aliasing code locally - need to discuss re-use, re-implementation etc)
• Get feedback from Befaco
• Get beta testers/feedback from VCV forums

Possible additional issues

• Merge / cleanup polyphony changes from https://github.com/martin-lueders/Befaco
• Update input/output ports of all modules to use Befaco bananuts (makes parsing module more clear)

Other

This is the fork where I am doing the work: https://github.com/hemmer/Befaco

Problem
EvenVCO can produce a pop when adding additional polyphony channels. It seems to be because previously unused/uncalculated values of phase / oldPhase / deltaPhase throw off the minBlep calculation.

Solution
The solution is to process the (currently serial) code that does the minBleps for a number of channels that is aligned with the 'simd size', i.e. rounded up to the nearest 4.

I noticed two issues with Sampling Modulator:

1. The DC offset correction doesn't look right. The output levels seem to depend on several factors and are never exactly 0V..10V or -5V..5V. Perhaps that's the hardware simulation? But the real issue is that even for a 50/50 pulse signal it's obviously not correct (-2.5V..7.5V), see picture below.

2. The trigg out produces gates when the internal clock is used and triggers when the external clock is used. I think it should be gates in both cases. Setup is the same as in the picture, just flip the int/ext switch on the right module, which is synced to the left one.

Fedora 23 Linux
Rack master (0.6.x)

Hi Andrew, I assume you already know this. The same is true (similar errors) for the ESeries and Audible Instruments repos. Please advise if the fix is simple. :)

[dlphilp@The6300 Befaco]$ make
g++ -Wsuggest-override -std=c++11 -I./pffft -DPFFFT_SIMD_DISABLE -fPIC -I../../include -I../../dep/include -DSLUG=Befaco -DVERSION=0.6.0dev -MMD -g -O3 -march=nocona -ffast-math -fno-finite-math-only -Wall -Wextra -Wno-unused-parameter -DARCH_LIN -c -o build/src/SpringReverb.cpp.o src/SpringReverb.cpp
src/SpringReverb.cpp: In constructor ‘SpringReverbWidget::SpringReverbWidget()’:
src/SpringReverb.cpp:266:40: error: no matching function for call to ‘rack::ModuleWidget::ModuleWidget()’
SpringReverbWidget::SpringReverbWidget() {
^
In file included from ../../include/rack.hpp:9:0,
from src/Befaco.hpp:1,
from src/SpringReverb.cpp:2:
../../include/app.hpp:63:2: note: candidate: rack::ModuleWidget::ModuleWidget(rack::Module*)
ModuleWidget(Module *module);
^
../../include/app.hpp:63:2: note: candidate expects 1 argument, 0 provided
In file included from ../../include/rack.hpp:9:0,
from src/Befaco.hpp:1,
from src/SpringReverb.cpp:2:
../../include/app.hpp:53:8: note: candidate: rack::ModuleWidget::ModuleWidget(const rack::ModuleWidget&)
struct ModuleWidget : OpaqueWidget {
^
../../include/app.hpp:53:8: note: candidate expects 1 argument, 0 provided
src/SpringReverb.cpp:268:18: error: ‘setModule’ was not declared in this scope
setModule(module);
^
../../compile.mk:56: recipe for target 'build/src/SpringReverb.cpp.o' failed
make: *** [build/src/SpringReverb.cpp.o] Error 1

Issue to track the work still to do before releasing Noise Plethora

Outstanding issues

• add DC removal option
• fixing playability of gritty noise
• making sure results are sample rate invariant (Teensy assumes 44.1kHz, I’ve tried to address this so far)
• port tooltips UI etc
• Code cleanup/documentation
  • use onAction() for knob pressess
• Remove debug messages
• Check performance is acceptable
• Check aliasing/DC offsets (Squinky Labs guide)
• Get feedback from Befaco
• Get feedback from Andrew
• Get beta testers/feedback from VCV forums
• Update changelog and push release to library

Builds / other

This is the fork where I am doing the work: https://github.com/hemmer/Befaco (branch v2-noise-plethora).

Like the object says: the trigger out is identical to the clock out when in internal clock mode. The clock out fires a 50% duty cycle square wave based on the BPM and the trigger out should output short pulses, instead it fires exactly the same output as the clock out. I don't know if this is the intended behavior but it sounds strange. In external clock mode it correctly fires pulses.

Issue to track the work still to do before releasing the next batch of modules. Preview below:

Outstanding issues

• Calibrate and tune modules against hardware equivalents (and schematics)
  • Muxlicer
  • ADSR
  • Sampling Modulator
  • Morphader
  • STMix
• Update graphics with SVGs from Befaco
• Check polyphony is implemented correctly
• Code cleanup/documentation
• Check performance is acceptable
• Check aliasing/DC offsets (Squinky Labs guide)
• Get feedback from Befaco
• Get feedback from Andrew
• Get beta testers/feedback from VCV forums
• Update changelog and push release to

Possible additional issues

• Investigate H. sync for poly EvenVCO

Builds / other

This is the fork where I am doing the work: https://github.com/hemmer/Befaco

I tried syncing two muxlicers, cabling the clock out of one into the clock in of another. The problem is that when I compare the all gates out of the two modules, it seems to take 3 clock pulses for the slave module to start sending gates.

(for clarity, this is also the case with any clock module clocking the muxlicer)

Just a note that Befaco needs to be updated to latest API since one or more modules uses outputs[].active

src/ABC.cpp: In member function 'virtual void ABC::process(const rack::engine::Module::ProcessArgs&)':
src/ABC.cpp:61:28: error: '__gnu_cxx::__alloc_traits<std::allocator<rack::engine::Output>, rack::engine::Output>::value_type' {aka 'struct rack::engine::Output'} has no member named 'active'
   if (outputs[OUT1_OUTPUT].active) {
                            ^~~~~~
src/ABC.cpp:67:28: error: '__gnu_cxx::__alloc_traits<std::allocator<rack::engine::Output>, rack::engine::Output>::value_type' {aka 'struct rack::engine::Output'} has no member named 'active'
   if (outputs[OUT2_OUTPUT].active) {
                            ^~~~~~
make: *** [../../compile.mk:62: build/src/ABC.cpp.o] Error 1

I tried chaining two Muxlicers via EOC -> One-Shot-In connections. Sounds like there's a timing hickup between the two (either way) and also an additional low pitch when going from 1 to 2. When I check the EOC trigger in a scope, it seems to come exactly at the same point as gate 8. Shouldn't it come after gate 8, maybe at the falling edge? Attached screenshot, can't attach saved selection.

Not sure how to resolve this

g++ -o plugin.so build/src/SpringReverb.cpp.o build/src/EvenVCO.cpp.o build/src/SlewLimiter.cpp.o build/src/ABC.cpp.o build/src/plugin.cpp.o build/src/Mixer.cpp.o build/src/DualAtenuverter.cpp.o build/src/Rampage.cpp.o build/src/SpringReverbIR.pcm.bin.o -shared 
/usr/bin/ld: i386:x86-64 architecture of input file `build/src/SpringReverbIR.pcm.bin.o' is incompatible with i386 output
collect2: error: ld returned 1 exit status
../../compile.mk:59: recipe for target 'plugin.so' failed
make: *** [plugin.so] Error 1

IS there a chance it would be ported? Thanks!

The issue occurs only if PonyVCO's 'Filter TZFM DC' option is enabled.

To reproduce

• Rack Engine SR is set to other frequencies than 192 or 768 kHz (please refer to #40 )
• PonyVCO's 'Filter TZFM DC' option is enabled
• Feed some voltages to 'TZ FM'
• Then disconnect 'TZ FM' source

Outcome

PonyVCO produces wobbling pitch after 'TZ FM' source disconnection.

After these steps there is additional step that leads to 'nanV' volts at output.
Just set Rack Engine SR to 192 or 768 kHz and touch the 'Timber' slider.

Please refer to the attached video for the details.

Win 10
PonyVCO 2.3.0
Rack Free Standalone 2.2.1

IS there a chance it would be ported? Thanks!

I think the VCV minblep code has a DC offset. I used to subtract it out in my VCOS.