If I was being paid to do this, I would of course keep on trying to figure it out until the end of time… 
1 Like
Haha, for sure!
Perhaps a red herring, but looks like removing or disabling the SheBang Talea module keeps your patch running…(The Palette engine modulation from the Caudal doesn’t appear to matter for the crashing if Talea isn’t active.)
I noticed. Also I’m seeing the crash in opaque widget rendering. Hmmmm…
I’ve seen the call stack go to various places during all these hours looking at this. It often ends up in the Palette process() code, but sometimes in the Rack Widget functions and also once into the Shebang module, which pointed me to look further into it.
I have more faith, perhaps misplaced, in Atelier.
Odd thing. All Talea does is operate the hit button, but even with that disconnected so it doesn’t change anything else, the crash still occurs. I’m putting my bets on a bug in the talea code therefore.
That simpler patch of your’s doesn’t crash for me when running Rack, but I get crashes when quitting Rack…(Running on Windows.)
I’m running it on Linux. I don’t use Talea, so I’m unsure it’s being used reasonably. The patch sends analog signals into three inputs even when that doesn’t make sense. (Should gate be a logic level? Is ext a discrete thing like a clock. V/Oct makes sense as analog.)
Incidentally, Talia is set to expect a clock on ext, so I’m thinking that both gate and ext should look like logic levels.
You might want to look at NaNs. If I feed a NaN from Racket Science RSMFH to Palette’s Poly Volts per Oct input, I can consistently crash Rack 1, with only these two modules and Audio-8 instantiated. This happens with both Linux and Windows.
On the bright side, Rack 2 filters out NaNs, so this kind of issue shouldn’t happen anymore.
Interesting. Do we have a float abnormality filter/detector in Rack 1?
I think I’m going to hack a little utility that colors leds to indicate the presence of ugly floats and suppress them in the output. Not a huge job.
1 Like
I’ve had to deal with this problem before, so my Grande Clip module also filters out NaNs and Infinities.
I didn’t bother displaying them since Rack 2 filters them all out. Just be aware that many/most of them are very short, possibly just a single cycle.
Oh, a very good observation! I connected the 1v/oct output of Talea into the VCV Scope, and indeed the Scope shows there are “bad” floats present.
Palette indeed doesn’t at the moment filter incoming nans and other abnormal floats, but I haven’t seen other modules doing that either…(I wonder if it is an expensive thing to do, I’d rather not add much more into the Palette CPU use, as it is quite a beast already…)
I’m aware. The idea is to toggle an indicator on and leave it on until the user resets it. I.e. say that somewhere in the past, corrupted data was seen.
I’ve seen modules go out to lunch when they see NaN. Crashing is unusual, although I guess possible…
I believe we filter out that stuff on MixMaster inputs as mixers by their nature are likely to be on the receiving end of bad output from other modules. I’m not sure how ‘expensive’ it was to do - Marc could tell you more about that - but it was certainly less expensive than getting the blame and feeling obligated to spend a lot of time tracking down the problem with users’ crashing patches when they were convinced it was the mixer causing the crashes 
Probably not worth spending time on now though as David says, Rack 2 filters out NaNs automatically.
I was able to fix the crashing when caused with the RSMFH module, but I am not sure if that is going to fix the original poster’s problem, it might go a bit deeper than Palette receiving NaNs in the inputs…In any case that was a genuine bug in Palette, thanks for the report! (Also that RSMFH module was a handy suggestion.)
1 Like
Some folk will continue to run Rack 1 as not everything will get ported. Same issue as some Windows plugs that will never be available as VST3.
2 Likes
Ok. Here’s a question. In the original patch, Talea is getting an audio rate non-clock input on ext. That’s an arpegiator step clock (either VC control or pulse counting), and that seems odd to me and way away from the module author’s intent. It was in pulse counting mode, and when I switched it to VC modulation, the patch remains running.
Unless you’re trying to fuzz test things, I really don’t see what’s being attempted. Since the crashes vary, I’m thinking that talea has some array that’s going off the end or it’s following a wild pointer.