From the original SynthMaker forum (2004–2014), with its members’ names and dates.
infuzion ·
😝 2 times in 2 days, which is better than before, but still not good. Happens when I load a few OSMs in the same SM session, either at loading another OSM, or closing one. Not sure if sending in a bunch of OSMs will help, since it happened with 2 different sets of OSMs. I'll keep monitoring if I see a pattern, but I'm not sure how much I'll be using SM now... cheers
infuzion ·
Still a few more sudden crashes, no SM reporter, & last one left no recovery files, even though there was time enough to save one.
Related suggestion: editor file & action tracking in .txt
sunsynth ·
Damn, i see this crashes here 2... 😝
In XP i even cannot kill the SM process - only suspend with process Explorer... Now i often can autoload my biig project (ASIO disabled as usual) again!
Sorry malc: i can't remember since when this started!
P.S: It happens at the end of the loading bar... w/o recovery or any crash messages and my schematic loads some setup TXT-files on startup...
btw: can u have a look why the Toolbox is so damn slow while SM autoload my biiig schem.?
malc ·
Is this something that only started with 1.1.5 or was it there before?
sunsynth ·
Hmm,
i think v115 do it more often...
Don't know if it's related but it seems to be a killer if i have my compiled exe started and closed before starting SM with the autoload! as i mentioned before it's my biig mixer project which load's some config files on startup!
btw: it kicks of while initialising here last crash.zip 4. Dec. the one before was v114 on 11. Nov.:
infuzion ·
malc wrote: Is this something that only started with 1.1.5 or was it there before?
Not too sure, SM always had a problem with no-report-crashes. I have not used SM this intensely since February.
trogluddite ·
Same problem here - since 1.1.3 at least, maybe earlier. I can work on an .osm with no stability problems for hours 🙂 , then save and close it OK usually - but loading a new one in without restarting SM causes a crash matbe 25% of the time 🙁 . I'm flitting between a lot of little projects while I learn SM - so it's not related to any particular schematic - but it does seem to happen less when there's no audio output in the schematic (ASIO or DirectX). I workaround by putting stuff into the toolbox that I want to use elsewhere, rather than have many .osms open at once for copy and pasting - so doesn't annoy me much!
Quad Core Q6700, 2GB, Yamaha mLAN ASIO driver, Windows XP Pro.
infuzion ·
It usually helps if you send the OSMs that were open in a single (per incidence) .ZIP file, with steps you had taken just before to support @ synthmaker. Better that you keep closing & reopening SM like it seems you do to keep the list of OSMs short though. 🙂
infuzion ·
infuzion wrote: It usually helps if you send the OSMs that were open in a single (per incidence) .ZIP file, with steps you had taken just before to support @ synthmaker. Better that you keep closing & reopening SM like it seems you do to keep the list of OSMs short though.
Speaking of which, I just got a straight-to-XP-crash-report after having SM open for only 5 minutes.
Emails are sent, I hope this is fixed soon, I'm getting tired of it. 😝
malc ·
Just need to pinpoint the steps that cause it. Thanks for the files. So far I haven't been able to get it to fall over here so any help you can provide in identifying the key steps would be much appreciated.
needaname ·
It happened to me two days ago, I was playing notes on the keyboard while moving a knob and boom, crash with error "synthmaker stopped working".
W7 here =)
MegaHurtz ·
As jou might know i do a lot of samplism stuff in code and such. Only green stuff I use is in the pitch to frequency and controllers. Although I do use lately some dynamic bitmaps and such for some decorations. My point is on that route I experience no crashes whatsoever, my guess is that it has to do with poly. shure this is a neccesary addon, I think the achilles heel is that the dsp is active atm changes in confusement about poly or mono streams is happening. I would bet you can stop this bug from happening if you disable sound when you start connection anything poly. I think this can be hardwired aswell. Needless to say?.. you`d never need the process of audio being able to happen while compiling.. You yust don`t.
infuzion ·
malc wrote: Just need to pinpoint the steps that cause it. Thanks for the files. So far I haven't been able to get it to fall over here so any help you can provide in identifying the key steps would be much appreciated.
You're welcome. I can't remember all I did. I wish SM could, thus this request: editor file & action tracking in .txt
stw ·
infuzion wrote: malc wrote: Just need to pinpoint the steps that cause it. Thanks for the files. So far I haven't been able to get it to fall over here so any help you can provide in identifying the key steps would be much appreciated.
You're welcome. I can't remember all I did. I wish SM could, thus this request: editor file & action tracking in .txt
Just want to second infuzions statement! I'm accustomed to SM crashes already (though i sometimes have the impression it got worse with 1.1.5). Since 20 or more versions of my current (big) project i can't even close the editor without a crash after a few minutes of work. I get sudden deaths from time to time as well. Not reproduceable and no way to track any cause (so no Bug report from me). However i guess it has something to do with memory allocation or something like that because it seems as if lots of undo steps support the crashes.
malc ·
Thanks for your input people.
I'd be surprised if a significant issue was introduced in 1.1.5 given the changes that were made though you never know for sure. My bet is that this is just one or two specific issues that only arise under certain conditions. I say this because I've had discussions with people who rarely have a crash. MegaHurtz is obviously in this camp.
I'm not convinced that the issues relate to having the sound enabled or disabled but if anyone wants to test this out I'd be happy to be proved wrong.
Some kind of logging would be very helpful. For me, the best thing would be a complete list of actions from schematic load to crash. If I could then play those back it would hopefully replicate the issue and I'd be able to debug it. I'll have to think about this as despite sounding simple it will probably take quite a bit of work to put it in place.
MegaHurtz ·
Im having second thoughts aswell, that would mean you`d have to keep audio disabled for as long as you have the poly disconnected. still.. Im glad I don`t need it as much as conventional synth makers.
aliasant ·
malc wrote: Thanks for your input people.
I'd be surprised if a significant issue was introduced in 1.1.5 given the changes that were made though you never know for sure. My bet is that this is just one or two specific issues that only arise under certain conditions. I say this because I've had discussions with people who rarely have a crash. MegaHurtz is obviously in this camp.
I'm not convinced that the issues relate to having the sound enabled or disabled but if anyone wants to test this out I'd be happy to be proved wrong.
Some kind of logging would be very helpful. For me, the best thing would be a complete list of actions from schematic load to crash. If I could then play those back it would hopefully replicate the issue and I'd be able to debug it. I'll have to think about this as despite sounding simple it will probably take quite a bit of work to put it in place.
I dont understand why the UNDO list cant be used as a logger. Its there already. Cant you make SM save that as a text file or similar so we can send that with the osm to you? Or even embedd it in the osm itself.
malc ·
Indeed, the undo list is exactly what would have to be used.
Just to be clear though, each action would have to be logged before going in the undo list. The undo list itself doesn't provide a complete enough snapshot of what has gone before because it only holds the current set of undoable actions. Any actions that went before but got undone are removed.
The approach is not a problem, it's just the work required to convert the data stored by each action to a format that can be logged. Easy enough but a fair bit of work.
aliasant ·
Wouldnt it be nice if you could use the undo list as a "step sequencer" ( best word I could think of) to play thru the steps one after the other OR click "play" and rapidly play thru all steps from nstart to nend with a pre configured delay between steps ?
Should make it easier to reconstruct.
malc ·
Absolutely - that's exactly what I was thinking.
I'm not opposed to this idea you know, just saying it will take time to put in place 🙂
aliasant ·
malc wrote: Absolutely - that's exactly what I was thinking.
I'm not opposed to this idea you know, just saying it will take time to put in place 🙂
Buy your wife and kids a 2 weeks vacation to, somewere far away, and start working. You could do this and some other crucial things if you work, say, 18hours/ day ?
Things to do.
Undolist to sequencer for faster bug squashing Multitouch SSE2,3 or what ever is possible to make SM coding faster. Lockable Modules. A new website were we can upload, download dlls we make + grade, and comment the dlls. Those with best average grades gets to visit you and work as your slave for 2 weeks helping to improve SM or simply take care of your children so you can work more efficiant :=) ( food and lodging included )
Tzarls ·
In the meantime, we could have some kind of screen grabber utility going on the background when trying to make SM crash. That way we could focus in the present bugs, instead of Malc focusing on adding new features to hunt down the old bugs, introducing new bugs in the process (because, well, it happens!).
Just an idea.
infuzion ·
malc wrote: I'm not convinced that the issues relate to having the sound enabled or disabled but if anyone wants to test this out I'd be happy to be proved wrong.
I just spent a few hours editing GUI-related OSMs and barely touching DSP, and not a single crash. Thing back the last few weeks, he crashes seem to happen more often when the more I touch DSP code, be it Code/ASM editing or green maths connected to Stream.
aliasant wrote: [Buy your wife and kids a 2 weeks vacation to, somewere far away, and start working. You could do this and some other crucial things if you work, say, 18hours/ day ? Things to do. Undolist to sequencer for faster bug squashing Multitouch SSE2,3 or what ever is possible to make SM coding faster. Lockable Modules. A new website were we can upload, download dlls we make + grade, and comment the dlls.
First, let's not get ADD here; no thread hijacking! Second, I am guessing Malc took the position at Outsim to work from home & be with the family. Third, I'm sure someone else can write an external website for DLL commenting... I would think Box.net or similar services have voting already.
Tzarls wrote: In the meantime, we could have some kind of screen grabber utility going on the background when trying to make SM crash. That way we could focus in the present bugs, instead of Malc focusing on adding new features to hunt down the old bugs, introducing new bugs in the process
I think a desktop movie capturing software is a good idea! Also, I've seen some videos that have a circle that follows the mouse, highlights when clicked, & a pop-up for keystrokes... anyone know good softwares for this please?
malc ·
aliasant wrote: Buy your wife and kids a 2 weeks vacation to, somewere far away
LOL, lord help me if they ever read this 🙂
infuzion wrote: I just spent a few hours editing GUI-related OSMs and barely touching DSP, and not a single crash. Thing back the last few weeks, he crashes seem to happen more often when the more I touch DSP code, be it Code/ASM editing or green maths connected to Stream.
Well I did say I'd be happy to be proved wrong. I was thinking that the issue might be more to do with undo but it was just a hunch. Then again your observations don't necessarily point to a compile issue. Assembler you have to be very careful with as you can easily make the software crash if you put a foot wrong. You can do it in the code comp too if you end up creating a div by zero. I know you're very careful though.
infuzion ·
malc wrote: infuzion wrote: ...Thinking back the last few weeks, he crashes seem to happen more often when the more I touch DSP code, be it Code/ASM editing or green maths connected to Stream.
...Assembler you have to be very careful with as you can easily make the software crash if you put a foot wrong. You can do it in the code comp too if you end up creating a div by zero. I know you're very careful though.
Well... I do sometimes crash SM due to my ASM & Code bugs also. 😊 I do not try to send in bug reports when it is my fault, though that also happens sometimes.
infuzion ·
Another sudden crash today (using one of the last files I sent you). I was cutting & pasting alot, some DSP (mostly for level meters), messing with Float Arrays, Selectors, etc... I copy/pasted the kirkagur/infuzion bitmaped knob into a new document, when I copy/pasted the "Knob Strip Loader" module that held the knob's bitmap array into that new doc, I got the sudden crash.
I then reopened SM, edited that knob some, copy/pasted/undo that same knob, then copy/pasted into the compressor I was working on before, & no crash.
infuzion ·
One thing I forgot to mention; sometimes when I get a crash in 1.1.5, the editor had become slow to respond for about 5 minutes before.. Takes 15 seconds to open a small OSM (that usually takes 1-2 seconds), slow to edit, slow to open right-click & title-bar menus... lag lag lag crash.
I was reminded when I tried to run this OSM. A large OSM (900k), so I expect it to be slow to open, but it became very slow to go inside the module, about 5 seconds, 2-3 seconds to open the menu... almost impossible to peek around since it was lagging so much. I gave up & closed it before it would crash.
MyCo ·
infuzion wrote: I was reminded when I tried to run this OSM. A large OSM (900k), so I expect it to be slow to open, but it became very slow to go inside the module, about 5 seconds, 2-3 seconds to open the menu... almost impossible to peek around since it was lagging so much. I gave up & closed it before it would crash.
Well this has nothing to do with SM itself, in this case it's because the wave player is buggy. There is a wave with more than 200.000 samples, and the player window draws 20.212 points and lines on the screen !!! The best way to draw a wave is to reduce the points that have to be drawn to less than the view width in pixel. And there is another bug in the wave drawing part, the connection between "wavearray" and "get Length" is wrong (samplerate is connected to array length).
trogluddite ·
Sorry to take so long getting back to you on this, I've started using a PC all day at work again - my eyes get too square to look at a screen at home as well 🙁
stw wrote: i guess it has something to do with memory allocation or something like that.
This seems to be the problem on my system. Several of the schematics I'm using set up large arrays in code modules e.g. mem[5000000}, for storing very long loops. When I open one of these schematics I can see the amount of allocated memory rise in proportion to the size of these buffers (using windows performance monitor). When I then close the schematic, the memory usage doesn't drop back down again to show that the memory has been freed up. Trying to load another schematic after this then causes a crash without error report. The memory does get freed up OK if I close SM completely.
Here's one version of the problematic files...
If you follow the audio path from the main audio input you'll soon get to the module 'New Looper' - not the best bit of code in the world, but that's where the big arrays are.
The Luddite
infuzion ·
trogluddite wrote: stw wrote: i guess it has something to do with memory allocation or something like that.
...When I then close the schematic, the memory usage doesn't drop back down again to show that the memory has been freed up. Trying to load another schematic after this then causes a crash without error report. The memory does get freed up OK if I close SM completely.
I'm guessing that also; SM has a history of memory issues. And I'm not excited about all the page faults also... since I've long noticed the more stable Firefox became though the years, the few page faults it makes.
trogluddite wrote: Here's one version of the problematic files...
I can repeatably get a "blue screen of death" by turning on my ASIO4ALL 2.7beta3(I think) using my internal sound, then closing out the crashed SM/XP crash report. I'm about to email off the SM report.
malc ·
Received thanks 🙂
MegaHurtz ·
@ the luddite.. Theres way cheaper ways of getting a forced integer than using the reciprocal.. (thats complex maths)
trogluddite ·
@MegaHurtz
Thanks 😀 - I really must start optimising this stuff as I go along - I keep getting carried away with adding new things and leaving all sorts of clumsy code lying around to trip me up later. Time to stock up on some very strong coffee and pluck up the courage to start turning this stuff into asm!
The Luddite
EDIT: P.S. Just recoded those forced integers - got a nice drop in CPU 🙂 , so thanks again for the pointer. P.P.S. Apologies to all for drifting somewhat off topic.
Jay ·
I still get the crashes also in 1.1.5 quite a few, where the audio hangs in a machine gun style until i hit the reset button
these are mostly happening if i change a patch whilst playing several notes at a time. this happens in most osm's i muck around with.
Mind you i do have a lot of modules that stem back to the early days of Synthmaker. i think i will do a clean install without adding my user modules and try some stuff, i will let you know if it makes any difference.
using AMD Phenom 11 Quad Core X4 945,ASUS M4A79T Deluxe mboard,win 7,4gig ram,E-MU 1616M PCI soundcard.
best regards
infuzion ·
Jay wrote: I still get the crashes also in 1.1.5 quite a few, where the audio hangs in a machine gun style until i hit the reset button these are mostly happening if i change a patch whilst playing several notes at a time. this happens in most osm's i muck around with.
As always, sending the OSMs to support @ synthmaker with steps to create the bug & your system audio specs are needed to really help Malc. cheers
Jay ·
Will do Infuzion! will rustle something up and send it in to malc a.s.a.p
Since I'm only a hobbyist with Synthmaker a wee crash now and again is no great problem, for me at least! but, the auto recovery not working at times is a real pain in the ass especially if i have made a lot of good changes before the crash 🙁
btw does the Auto recovery (when working) cause system slowdowns and excess fan use on your systems at the periodic saving of the backup file? any of you? or is that just me? 😕
Best regards
infuzion ·
Jay wrote: btw does the Auto recovery (when working) cause system slowdowns and excess fan use on your systems at the periodic saving of the backup file? any of you? or is that just me?
On my old laptop it did, more often when the file was larger & I was running a high CPU% OSM at the time.
TIP: Always save right after a good edit as a different file name.
Jay ·
oh i will try that Infuzion! thanks for the tip!
best regards
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker