From the original SynthMaker forum (2004–2014), with its members’ names and dates.
NothanUmber ·
I'm really getting frustrated slowly, SM is crashing every 5 to 10 minutes for arbitrary reasons (sometimes with a recovery backup sometimes not, so I had to do many things several times), sorry working that way isn't really fun any more...
Here one of the (too) many recovery file that crashes immediately after opening it:
http://home.in.tum.de/~strixner/WindStr ... overed.osm
(sorry, I can't remember what the last thing was before it crashed in this specific case I just took an arbitrary one out of my collection...)
And here a current work in progress version that doesn't crash (at least immediately...) for comparison. (It seems to work but is still very sluggish mainly because of the BSwitchTrig bug I already posted a "demo" for and very unreliable. The unreliability (the transpose multiplicators sometimes seem to be stuck and a note has to be played several times until the right value is set up) could have to do with my "Ugly Pseudo Delay" component (I had a similar problem in bidule until I introduced a delay - unfortunately there is no proper "green" delay or any other synchronization possibility for green calculation paths in SM so I had to make a quite ugly pseudo component as the name says 😉 ):
(There are many sub components that could be of general interest inside this schematic (mainly a set of more high level "all purpose midi components") so if someone is interested: take what you can use but at your own risk) I'll be off until wednesday, then I'll gladly try to answer any questions you should have in that direction (most things are pretty self explanatory though) and will try to fiddle around with the whole schematic at for least some more time.)
(Bidule users can compare this version to the more usable (but a little bit cpu intensive) version - perhaps I simply made some mistakes by converting the logics to SM, it's a little bit late now... 😉 ):
http://home.in.tum.de/~strixner/WindStr ... _04.bidule
Greetings,
NothanUmber
NothanUmber ·
Hm strange, I have to open and close the *_recovered.osm file several times in order to provoke the crash and once I "managed that" the "normal" WindStringController_01.osm file is also crashing SM until I restart my computer... whateverthismeansiwontsolvethattodayanymore...
Greetings,
NothanUmber
NothanUmber ·
Hi,
hope I didn't sound too negative yesterday (or should I say today 😉 ), was just a little bit frustrated because of all the crashes. Haven't been able to reproduce the crash with the *_recovered.osm today (but there is no midi equipment connected to my computer now so that could be the reason.)
Greetings,
NothanUmber
malc ·
No problem with you sounding negative NothanUmber. Believe me, the current instabilities are very frustrating for us too. It's going to take a little time to get everything back to the stable state we were in prior to the arrays but rest assured that we will get there.
Thanks for being so patient in the mean time. I'll have a look at all this in detail tomorrow.
Malc.
malc ·
Ok, well I'm having the same problem as you now - I can't reproduce the crash. It's possible that when it crashed the first time it was for some other reason and in doing so it left MIDI devices open. A reboot would solve the problem.
I'll look a bit more into this. Let me know if it crashes again and if possible what you did to make it happen.
Thanks.
rl ·
Hi malc,
I did the following observation: After closing SM my midi-OX - midiyoke combo behaves strange - pending midi events are transmitted very slowly (avg. 1 midi message in 2 sec.). Midi Yoke hangs on exit. To cure this problem I have to start SM again: all pending midi messages are then transmitted in one go, but only if I activate the midiyoke input port. The selected port name in the portlist of MidiIn sometimes disappears.
infuzion ·
rl wrote: I did the following observation: After closing SM my midi-OX - midiyoke combo behaves strange
That brings up a good point; perhaps we should post our full config somewhere (wiki?) to help the devs. Esp when it comes to VST(i) hosts, CPU, soundcard...
NothanUmber ·
Hi,
spent some more time on analysing this strange bug. It seems to have to do with the midi out but here the whole story (perhaps an observation that seems to be secondary to me is just the piece of information you need):
* the bug only appears if I have my emagic mt4 midi-usb adapter attached
* if I load the _recovered file and exit synthmaker the synthmaker-process doesn't terminate properly (the window closes and all but one can see that the process is still alive in the task manager)
* synthmaker seems to survive 3 to 4 starts (we have 3 or 4 processes then) before it set's the hardware (presumably the midi interface) into some strange state that let's SM crash at all subsequent tries to load the *_recovered file
* manually killing the running SM processes after exit doesn't help, it's the contrary: then SM will crash in every case once one tries to load the _recovery file the next time
* loading any other files from my collection except the WindStringController_01.osm or WindStringController_01_recovery.osm doesn't crash SM even if it's already in "crashing mode"
* If I save a version of the WindStringController_01.osm where I unselected any midi outdevices I can load this version even in "crashing mode" (just selecting another midi out device (another midi yoke, a mt4 output, the output of my edirol um1 usb-to-midi converter) doesn't help any selected midi out will crash in cr-mode)
* I found that if I load a "MagicRepairFile.osm" that just consists of a MIDI in that has a midi yoke in enabled and that is connected to a MIDI out that has another MIDI yoke selected then SM seems to recover itself and I can load the crashing files again (but they'll crash after 3-4 starts as before, then I can't load them anymore - until I reload the "MagicRepairFile")
Here some debugging output files:
ERRORLOG.TXT and CRASH.DMP
Hope that helps,
NothanUmber
P.S.: Will gladly have a look at any let's-see-whether-the-bug-is-solved temporary test versions 🙂
P.P.S.: This was tested with SM 0.9.3x
NothanUmber ·
Another day another bug update 🙂
* have built a new variant of the WindStringController_01_recovered.osm file where the mt4 inputs where disabled (so there is no input enabled at all) only the midi outs via midi yoke are enabled. This file behaves in the following manner:
- If the mt4 is not connected there is no problem as before
- if the mt4 is connected and one exits SM there are no open processes left now (one can see that the mt4 never switches to usb mode and stays in patch bay mode as the leds don't change their color)
- after about 3-4 starts SM nontheless hangs. (Now not with a "proper" crash but the "Loading..." message stays and nothing changes until one kills the process
- the MagicRepairFile seems to help in that case, too (the _recovery file loads 3-4 additional times after loading this osm-file)
- after unloading the mt4 drivers everything is working flawlessly again without a restart of the computer (or loading the MagicRepairFile) - the "only" disadvantage is that I can't play my instrument any more then...
* Synthmaker is the only program that has problems with my mt4 adapter. Don't know whether that's a specific problem with the emagic drivers or with the fact that the mt4 has 2 inputs and 4 outputs (my edirol um1 doesn't make any problems - it has only one input and one output though)
P.S.: The UM-1 was disconnected during these tests so it's not a strange interaction problem between these two adapters (shouldn't be a problem anyways - I use both adapters together all the time in other applications)
Greetings,
NothanUmber
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker