yes now I know what you want 
Thank you for the updated patch and description. I will debug this soon. As a first thought, the input values might be clamping their range incorrectly.
Hi,
I downloaded the macOS alpha build 54 and installed to /Users/alan/Documents/Rack/plugins-v1/IggyLabsModules but the plugin does not load as it’s not trusted…
I’m running macOS Catalina version 10.15.6 (19G73).
I normally build using the Rack SDK. Do you have a repo anywhere? I can try and build it for you on my Mac and see what happens.
Thanks, Alan.
Not sure if this would help, but have you tried deleting the autosave-v1.vcv file in your Rack folder, then launching Rack and trying out the plugin?
Sure, thanks! The branch is here: https://github.com/IggyLabs/IggyLabsModules/tree/dev-more-ideas.
One other thing I haven’t implemented yet but might help the issue is subsampling parameter modulations. Right now audio rate modulation of rules and seeds will mean doing lots of recalculations to get the display rendered since it computes the entire grid on changing rule or seed.
1 Like
OK. Builds OK for me when I use the Rack SDK locally on my Mac, with a couple of warnings…
$ make -j16 install
…
In file included from src/view/table.cpp:9:
In file included from src/view/../dsp/osc/wavetable.cpp:6:
src/view/../dsp/osc/../../dsp/osc/earlevel/WaveUtils.cpp:100:31: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
for (int idx = 1; idx <= maxHarmonic; idx++) {
~~~ ^ ~~~~~~~~~~~
src/view/../dsp/osc/../../dsp/osc/earlevel/WaveUtils.cpp:113:28: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
maxHarmonic = temp >= maxHarmonic ? maxHarmonic - 1 : temp;
~~~~ ^ ~~~~~~~~~~~
2 warnings generated.
…
Made a patch (attached). No idea what I’m doing but looks real fun! 
more-ideas-test-1.vcv (8.2 KB)
1 Like
The CPU meter doesn’t seem to be complaining…
1 Like
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
1 Like
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.
1 Like
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.
1 Like
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.
2 Likes
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.
To get started, you can try these two patches to play around with: quant_mode.vcv (7.4 KB) raw_mode.vcv (8.1 KB)
EDIT: documentation is mostly done and here
2 Likes
I’m a big believer in doing that!
1 Like
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.
1 Like