Witch crashing with fascination machine patches Web midi on chrome not playing nice when device disconnected

OWL
#1

Hi folks,
I’ve been exploring the owl patch library, amazing stuff! Is it the case that some patches are only suitable for certain OWL devices? The Fascination machine patches seem to crash my witch after a few seconds of playing. CPU will show over 100% and sound stops, possibly tied in to turning up the intensity control.

On a related note: Chrome (Win10) will hang quite thoroughly if I disconnect my witch (or it crashes) when either the patch library or witch.rebeltech.org are connected. I usually have to terminate chrome via the device manager to get it back. Is this normal for web midi stuff?

Keep up the good work!

Robin.

#2

That’s not expected at all. You could try building a copy of that patch (without making it public) to see if that makes any difference. Does it happen for every FM patch or just specific ones?

#3

Ah, it seems FM V is the one that will crash … could have sworn I had some trouble with IV and III too, but all seems stable now.
However V has crashed 100% … I’ll try a build once I work out how :slight_smile:

Cheers,
Robin.

#4

Hmmm … I can’t get a successful online build of fascination V … Think I did everything right: downloaded three files off the tabs of the original patch, imported them into a new patch ( https://www.rebeltech.org/patch-library/patch/fascination_V_test if you can see that? ) but compile gives this error on stdout:

  1. e[91mErrore[0m pd2hv: _main.pd in “_main.pd” @ (x:0, y:0): Don’t know how to parse object “pingpong5~”. Is it an object supported by Heavy? Is it an abstraction? Have the search paths been correctly configured? 2) e[91mErrore[0m pd2hv: _main.pd in “_main.pd” @ (x:0, y:0): There was an error while connecting two objects. Have all objects been correctly instantiated? Have all inlets and outlets been declared? 3) e[91mErrore[0m pd2hv: _main.pd in “_main.pd” @ (x:0, y:0): There was an error while connecting two objects. Have all objects been correctly instantiated? Have all inlets and outlets been declared? 4) e[91mErrore[0m pd2hv: [comment text] in “_main.pd” @ (x:0, y:0): Connection made to non-existent inlet at [comment {u’text’: ‘null object placeholder (pingpong5~)’}]:0. 5) e[91mErrore[0m pd2hv: [comment text] in “_main.pd” @ (x:0, y:0): Connection made to non-existent inlet at [comment {u’text’: ‘null object placeholder (pingpong5~)’}]:1. 6) e[91mErrore[0m pd2hv: [comment text] in “_main.pd” @ (x:0, y:0): Connection made to non-existent inlet at [comment {u’text’: ‘null object placeholder (pingpong5~)’}]:4. 7) e[91mErrore[0m pd2hv: [comment text] in “_main.pd” @ (x:0, y:0): Connection made to non-existent inlet at [comment {u’text’: ‘null object placeholder (pingpong5~)’}]:2. 8) e[91mErrore[0m pd2hv: [comment text] in “_main.pd” @ (x:0, y:0): Connection made to non-existent inlet at [comment {u’text’: ‘null object placeholder (pingpong5~)’}]:3. 1) e[93mWarninge[0m pd2hv: _main.pd in “_main.pd” @ (x:0, y:0): This graph contains an empty object. It should be removed or defined. INFO: make exit code is 2.

stderr gives:

mv: cannot stat ‘/tmp/owl/owl-build-lGT17q/c/*’: No such file or directory make[1]: *** [/tmp/owl/owl-build-lGT17q/Source/Heavy_owl.h] Error 1 make: *** [heavy] Error 2 ERROR: Patch build failed.

It looks like it can’t see the pingpong5 file, but it’s definitely there on a tab. Any clues?

Cheers,
Robin.

#5

You’ve ended up with an underscore _ instead of tilde ~ in the filename when downloading the file.
Rename the file pingpong5~.pd and you should be good to go.

It is possible however that the firmware overheads on the Witch are slightly higher than Alchemist and Wizard, as it does a few more things like more advanced CV smoothing and attenuvertion. If the patch already runs near 100% this could tip it over. A quick test now shows this seems to be the case.

Good new is we’ve done some optimisations on the patch compilation side since publishing this patch, and recompiling it yields a much better performance: 74% on the Witch.

If there are any other patches that perform poorly let us know and we’ll try to recompile!

#6

Yeah this seems to be a deep Windows bug affecting Web MIDI. Whenever a USB MIDI device resets, there’s a good chance that the browser (same with Chrome or Edge) hangs, often in a really ugly way. Usually terminating all the browser tasks in Task Manager clears it up. Never did manage to find a better remedy, even when the reset is expected - no combination of closing the device connection or reloading the page seems to make a difference. Also the error frequency varies a lot between windows installations. On some machines it just never seems to happen, while on others that appear to be identical in OS, browser and driver versions it happens every time.

#7

Ah! effing windows! Well spotted, thanks :slight_smile:

And thanks for the optimisations, currently listening to happy tweetings :smile:

#8

Oh well, I’ll just hope that my system eventually converges on one of the more stable configurations one day. Shame as it would be a really slick experience otherwise.

Cheers,
Robin.