Just got my second Organelle (liquidated my first one in a eurorack frenzy, you know) and really loving having this thing back. Especially now with Orac being a thing. But I’m having major crashing issues. Specifically with the brds and brdsmpe patches but happens occasionally with other patches as well. Happens very often when I switch OSC algorithms in brds. And this is me using the patch alone, no Orac involved. It was brought to my attention that this Organelle is from the first batches in 2016 and I’m wondering if the older models had different processors or something? Cause the last Organelle I had (which I had bought new in 2017) had few and far between crashes (though I don’t think I tried the brds patch). Should I do a factory reset? Or get rid of some patches I don’t use? (Though the drive isn’t anywhere close to being full) Is it possible I installed the patch incorrectly? Anyone else have these kinds of issues?
Well all of the Mutable Instruments patches are conversions of code which wasn’t designed for the Organelle and are (as far as I know) specified as work in progress. Not sure if you can blame the hardware here… Do you get crashes with other patches as well (C&G patches)?
My Organelle is rather new (end of 2017) and don’t think it has ever crashed on me (but I have never used the Mutable patches…)
there is a bug somewhere in the brds code… which affects the brds module in orac, and the standalone.
basically its some combination of parameters with a particular shape that does it, unfortunately ive not as yet worked out which…
I think people trip over it, when they happen to have some of the other parameters at the ‘bad’ value, and then switch shapes.
yes, its crashing in the MI code, but its not a bug there as such, rather, a boundary condition that probably needs explicit checking in the my external.
unfortunately, until I find the rogue values, its hard to me to track it down… and ive been kind of busy
btw: Id recommend more explanatory post titles, so that its a little clearer what your real issues are … rather than a ‘it crashes’ title.
Thanks for the responses! Just wanted to make sure I wasn’t the only one experiencing this.
And yeah the title could be a bit more specific but at the time I made it it seemed like more than just the BRDS patch was crashing so I thought maybe it was an OS problem. Now it seems I can’t replicate the crashes outside of the mutable patches. I guess I’ll stick with my hardware braids and rings for the time being!
whilst playing with something else , I found the cause of this bug - as suspected, its a boundary condition.
happens on some shapes (=oscillators) where timbre or colour is 100% (exactly), so for now just avoid 100% … in orac you could edit the colour/timbre limits to 99% if you wish, in the module file, and then it wont trigger.
this bug was also in the standalone brds patches.
I’ll re-release them at some point…
and the braids modules will be fixed in next version orac when it’s released.
from memory I think there is an similar issue in lmnts (elements) but as yet, not found the right combo of parameter values to crash it
If I remember correct it happen if you set the colour or timbre to a higher value than 0.99 or is it above 1.00?
If you do that, it crashes PD. I fixed by just setting a limit beforr I send the values to the object. But could be fixed internally in the object by setting a limit, to make it more safe from crashes.
There is also something with the trigger function. On Axoloti there is a trigger inlet which can be used to trigger the drums and the plucked instruments. On this version the only way to trigger these algos, is to send a new pitch value. If you send the same pitch value 2 times after each other it does not trigger a new “hit”, only when a new pitch value is set, it triggers it again.
But yeah, it would be really great if this version also had a dedicated trigger inlet. Triggering the pitch inlet could work too, but then it should be possible to also trigger the same pitch twice in a row and not having to switch pitch for it to happen. This is probably some kind of error in a logic statement, somewhere in the code for the pitch inlet > it only triggers the algo when a new value is send. That sounds like a “logic error”.
I just checked the code for Brds and now I am pretty sure that the trigger error can be found in these lines of code:
// Check if the pitch has changed to cause an auto-retrigger
int32_t pitch_delta = pitch - x->previous_pitch;
if (x->f_auto_trig &&
(pitch_delta >= 0x40 || -pitch_delta >= 0x40)) {
x->trigger_detected_flag = true;
}
x->previous_pitch = pitch;
Think I am going to try some thing out in the weekend, to see if it can be fixed. It really should always trigger a new hit when send a pitch value, instead of only when the pitch changes. . Or maybe a dedicated inlet would be better…
99.9964% , but given the resolution of the encoders is 0.097%, it should only be 100% … but perhaps if there is some missed jitter flicking it to 100% briefly (though Ive not see this)
in axoloti the trig is only used on the percussive element, but those also have a couple of other things missing if i remember correctly.
on the eurorack module this is because it has an internal vca, this is kind of not needed for non-percussion modes when in software , as there is no cost to adding your own… but you still need to strike the percussive elements … there are similar ‘questions’ when it comes to rings, clouds and elements.
I meant to put these in after initially releasing braids, but then got sidetracked onto other MI stuff, and then Orac.
at some point I’ll add a trig inlet … and also do auto trig as that has its useful…
Im also going to ‘review’ all the externals, as I now have a few of the eurorack modules (incl, rings, elements and plaits) , so Ive a much better idea of how they work.
also … I did both the axoloti and pd/organelle implementations before VCV rack, so had to figure it all out, now I have the option to check its implementation to verify what Ive done etc.
but my first priority is porting plaits and marbles (and probably a better rings implementation) … and orac 1.1
(imo, I think plaits is better than braids… it really does largely replace it, even in a software guise)
so quite a few things to do, just a matter of finding time to do it all.
Yeah but the original braids has got the same trigger inlet for those percussive sounds. It is an important feature and needed to be able to use the percussive sound in a proper way.
It seems like the PD version uses the pitch inlet for the auto trigger and only triggers when changing pitch. So basically if you want to trigger one of the percussive sounds 2 times at the same pitch, that is not possible.
Sounds great! Plaits is very close to Braids, but a bit more advanced. They are similar but also not at all, as they dont share any code
Yeah might as well use them as cross reference and makes things easier and get better implementation
