The CPU meter doesn’t seem to be complaining…
The CPU meter doesn’t seem to be complaining…
Thanks for testing out for me!
(The two warnings should get taken care of… That code comes from a library I use in the Table module.)
Right on. The CPU looks good to me! Subsampling might still keep it lower ;D
With the new patch, Rack crashes after half of a second but with a different Log:
8: 1 Rack 0x0000000104c7d3cd _ZL18fatalSignalHandleri + 45 7: 2 libsystem_platform.dylib 0x00007fff7a1eef5a _sigtramp + 26 6: 3 ??? 0x0000000000000000 0x0 + 0 5: 4 plugin.dylib 0x000000000c384e9d _ZN10More_ideas7processERKN4rack6engine6Module11ProcessArgsE + 2333 4: 5 Rack 0x0000000104cd49be _ZN4rack6engineL18Engine_stepModulesEPNS0_6EngineEi + 462 3: 6 Rack 0x0000000104cd55ab _ZNSt3__114__thread_proxyINS_5tupleIJNS_10unique_ptrINS_15__thread_structENS_14default_deleteIS3_EEEEZN4rack6engine6Engine5startEvE3$_0EEEEEPvSC_ + 1419 2: 7 libsystem_pthread.dylib 0x00007fff7a1f8661 _pthread_body + 340 1: 8 libsystem_pthread.dylib 0x00007fff7a1f850d _pthread_body + 0 0: 9 libsystem_pthread.dylib 0x00007fff7a1f7bf9 thread_start + 13
If you delete the autosave-v1.vcv file and then open the patch Alan used, do you also get a crash? On MacOS 10.15.5 your
more crashes.vcv patch is working fine even with adding more LFOs to seed and rule and wiggling the knobs with the mouse at the same time.
sorry but there is no difference with or without autosave it crashes. Possible its a OSX version related problem.
Okay, I’ll need to find more OSX testers. Thank you for reporting the issue.
Just tried your patch using the version of the plugin I built locally using the Rack SDK and it works fine for me. I connected the LFO output to the Rule and Seed inputs and turned the knobs manually and nothing crashed. I’m using Rack v1.1.6, if that matters.
Finally took the time to try more.ideas. Very neat!
I have not taken the time to look up in detail how it works, but I’m getting some cool patterns out of it! I like how I can send it a new seed every 4 bars and get new but musically related material.
Since I don’t know how it works internally it might be a stupid question, but any way to get raw unquantized CV out of it? I’d like to integrate it to my own quantizing system instead. I’ve been using the chromatic scale output for that.
Gratuitous patch vid follows.
That patch sounds awesome!
In its current form more.ideas quantizes in the same way as the script the module is modeled after (less_concepts). It does this by taking the current “generation” (the eight bit number shown as the eight lights), changing to base 10, and scaling it within the range of the high and low values, then mapping to a scale. I hope that sort of makes sense.
Here’s a little example. Say your current generation is (in decimal) 156. The eight bit generation value can range 0-255, meaning your generation scales to 0.5 since you’re halfway through. Then you take your high and low params, multiply by that scale. So say your low is 0 and high is 14, and you then get 7. That value gets mapped to the seventh scale degree of the scale that you’re in. That gives the MIDI pitch number that will then be output of V/Oct.
Raw CV could potentially just take the raw scale value (0.5), map it to a CV range, and spit that out.
In proper documentation, I’ll have to be careful about using the word scale to mean two separate things.
This is all to say: I also would like to output raw CV to feed to external quantizers, which is totally possible. It is next on the list and should be in my next tester builds I’ll post.
New build with a few tweaks is here.
There is a toggle for unquantized (raw) / quantized CV output as per discussion with @Aria_Salvatrice , and there is also a toggle for whether the CV should change when the selected bit is triggered or when the incoming clock gives a trigger.
Changing the range of the raw CV output is available in the right click menu. Note that in raw CV output mode, the low, high, and scale parameters do not change anything from the output.
I have a little refactoring to do and documentation now! I am pretty happy with the features implemented now.
EDIT: documentation is mostly done and here
I’m a big believer in doing that!
Still crashes with the new version when the Rule or Seed is modulated by CVs or manually set
Now the log reads:
[115.470 fatal src/main.cpp:45] Fatal signal 11. Stack trace: 8: 1 Rack 0x0000000102bcc3cd _ZL18fatalSignalHandleri + 45 7: 2 libsystem_platform.dylib 0x00007fff7756af5a _sigtramp + 26 6: 3 Rack 0x000000010305f217 GlobalIsTargetPlatformNative + 46767 5: 4 plugin.dylib 0x000000000a2a4dc1 _ZN10More_ideas17subSampledProcessERKN4rack6engine6Module11ProcessArgsE + 2865 4: 5 Rack 0x0000000102c239be _ZN4rack6engineL18Engine_stepModulesEPNS0_6EngineEi + 462 3: 6 Rack 0x0000000102c245ab _ZNSt3__114__thread_proxyINS_5tupleIJNS_10unique_ptrINS_15__thread_structENS_14default_deleteIS3_EEEEZN4rack6engine6Engine5startEvE3$_0EEEEEPvSC_ + 1419 2: 7 libsystem_pthread.dylib 0x00007fff77574661 _pthread_body + 340 1: 8 libsystem_pthread.dylib 0x00007fff7757450d _pthread_body + 0 0: 9 libsystem_pthread.dylib 0x00007fff77573bf9 thread_start + 13
Tried several different modulation sources without any positive results, LFOs, Walks or the random sampler and so on
I took a quick look and couldn’t produce any crashes (on Windows) but there is a memory leak:
@iggylabs First, you shouldn’t allocate memory on the dsp thread at all, second, there is no
delete for the previously allocated memory.
Thank you, Ben! Still learning proper memory management and C++. I’ll get on fixing it soon and update the builds.
Is it better to initialize the pointer to the CA object on the module initialization, then update the object (not create or destroy) within the process code?
Yes, this would be way better.
Latest build here.
This should fix the memory leak. I only create the CA (cellular automata) object once when the module is created. I then update the 64 x 64 cellular automata vector when the rule/seed params change instead of creating a new CA object.
While making this fix, I started to see crashes when I changed the rule/seed too quickly as @jue was seeing. I fixed this by only drawing the visual when the CA object has finished recalculating the full 2D cellular automata vector.
I tested modulating seed/rule at audio rates and crashes were gone. (You won’t get any good results out of the module by modulating at those rates, so it’s not suggested, but now it shouldn’t crash even if you ramp the frequency up very high.)
I wonder if this fix helps your issues @jue?
EDIT: Noticed that I need to add a few things to the raw CV output mode range. It isn’t saving settings when reloading patches; it always goes to -/+ 10V mode. I’ll also add check marks to the menu…
The last build fixes all crashes here
Thank you for your work!
Just a few small tweaks (saving raw CV range output from context menu + a checkmark for the selected range), but the first version of more.ideas should now be stable.
I will wait a few days before submitting to the library, but if you do not want to wait until then, I have builds available.
I don’t know if I’ve already spammed you with this, but for a little more on what you should avoid doing on the audio thread, this document goes into it a little bit: https://github.com/squinkylabs/SquinkyVCV/blob/main/docs/efficient-plugins.md