Hey Jean or others. In 6.15 and 6.14 I’m noticing crashes in patches that involve loops Repeat-N playing of sound, midi, and looping calls to other system processes (Microsoft speech synthesis in particular) , although the same patches in 6.12 seem to be more stable. Any guess on this? Can attach an .omp if you like. Thanks!
Leonard
Hi Leonard,
yes, please send a minimal patch or example.
I’d need something “more” minimal / self contained. I can’t use the patch as it contains a number of your own functions (pic-chooser, pick-fro-reader, speak, etc…) that I don’t have. Please try to isolate a simple case provoking crash, with as few dependencies as possible to your own code. Thanks,
Hey Jean. Sorry, forgot to mention, the functions are in a lisp file in the zip . The only thing that may not translate to a different system are the (speak) functions, but even with those calls removed from the main lambdas, the patch still crashes in 6.15.
Sorry for the confusion!
ok – I will not be able to try it on Windows before a few days, but in the meantime if you can, make a really minimal example (for instance if the calls to your “speak” function are not required to get the patch to crash, then remove them, etc.) The zip folder has 56 files in it. I’m sure I don’t need them all 
Thank you !
Sorry about that Jean 
(My thought in including those was just in case it was the random processes that pull from large file lists that was crashing it) I’m glad I’m going through the exercise of pairing down the patch though, as I’m finding that a simplified version doesn’t reproduce the error. Will put a new patch up when I can reproduce the error in a dependency-free and non system-specific form. My hunch is that it’s related to creating a new thread and calling a system process, i.e. (mp:process-run-function “process” nil (lambda () (sys:call-system ( [some system process here] etc. . .but I’m just guessing. Thanks again for looking at it though!
Hey Jean. Was able to isolate the crash. Looks like it wasn’t system-dependent or some of my other guesses, but somehow simply related to playing a sound object and a score object in the same loop. You can test it with either the sound file attached or any other of short length (couple seconds). This crashes in 6.15 but not in 6.12. Thanks!
crash isolate.omp (37.7 KB)
Thanks, this is helpful.
However I don’t understand what is intended in your patch. Since you have a 1s sleep call at each repetition, the play will be called again after 1 second, and therefore the score object in the maquette will never sound (except at the last repetition), as every new play stops previous playback and starts over.
The patch doesn’t crash here on a Mac anyway. I will try to test it tomorrow on Windows.
Are you using default audio and MIDI players ?
… in other words, do you really need all the maquette thing to get the path crashing, or wouldn’t it be the same with just a sound like this ? Can you try ?
Thanks Jean. My error on the sleep, 6 seconds instead of 1 gives it enough time to play both objects during a loop. Still crashes in OM 6.15 after a few iterations. Simply repeat-n-ing the sound file by itself as you suggested does not cause a crash. I’m using the maquette here so I can render different midi instrument sounds for the score object, and to achieve a degree of overlap (simultaneity) in the sounding of the wav file and score object. I tried loop playing the objects as in the attached screen shot, with appropriate sleep values , and did not get a crash, although that way this doesn’t allow for the option of overlapping sounds, as I understand.
Still blind-guessing here, but as I see it there is no possibility of overalp since the sound is ±1700 ms long, and the poly starts at 2500…
I’m curious to know why are you doing this, by the way ? Wouldn’t it be easier to build a single maquette containing all the sounds and POLYs and then play it ?
To your second question, some of the events I’m including in the main loop of the actual patch I’m dealing with involve both system calls (windows speech synthesis specifically) and picture instances that are dynamic and refreshed multiple times with a single main loop. I had assumed some of these things aren’t maquetta-able the way I’m using them, but I’m interested in taking a deeper look…
You can actually isolate even more your problem I think, as it does not seem to depend on the score/MIDI part of your patch. In fact, you can get it to crash with just a slightly modified version of my previous example:
In this case the difference is that the SOUND object is being (re)created from the audio file on your disk at each new repetition. This is also what happens when you put a sound in a maquette : the SOUND object is copied, and the new one is also initialized from disk.
So there are two concurrent accesses to the sound file: one for loading the object, and one for playing it.
After OM 6.12 I have used a new build and version of the audio library, which apparently does not support this very well…
The bottom line is, I’m not sure I can solve this problem so easily right now. But I’ll keep you posted if I do.
On a side note, I would actually recommend not to use the PLAY box within such kind of iterative process. PLAY is a quite basic box which triggers an asynchronous call the OM player and actually does not really fit within a functional graph.
Interesting, and good to know. Thank you for putting in the time to figure that out, Jean.