1.1.2: SM crashes ALOT...too much for me to take!

Tom7777 · 8 Oct 2008

Yeah im pretty much the same at the moment, still interested but not focusing on SM so much, i get crashes all the time even if it's 'stable' according to other users, i do send logs and osm's whenever i can but i always seem to make SM crash somehow and i have had lots without the reporter also. I don't think you sound like a whiner at all imo even though some users will, your just giving your true thoughts and i find a lot of users won't be so open about cpu, load times, slowdown, crashes etc but if people don't mention things then nothing ever gets sorted. Im hoping there will be a update soon addressing various important issues as SM definately allows for great things it just needs to be fixed for various things. 🙂

electrogear · 8 Oct 2008

Hi Tom, Mike here, yes the guy who's built the schematic that's causing you problems (sorry if any of it is my fault!). Have you tried rolling back to the last version? (1.1.1)? This is the version I used to build the schematic, and after a while you kinda get to know what makes it crash and just have to avoid certain actions. I found it was very laggy at one point, and I narrowed it down to some big multiplexers, which I replaced with big banks of selectors. This eliminated editing lag for me, but increased CPU somewhat (I *think* - although I could never quite be 100%). Since then I haven't had too many problems with crashing or lag. I was running XP SP2, and a Core2duo 2.6Ghz. I've not touched the project for about 2 months, so I'll need to get back into the swing of things, and I'll test it out on the latest version too and let you know how my system handles it.

I'll send you a private email later rather than discussing work through the forum, but I thought this was relevant to the topic.

Cheers,

Mike

aliasant · 8 Oct 2008

I used to have a lot of crashes but lately not so much. But.... When I export my big synth as a VST and use it in Reaper it crashes. It might take a minute or two but eventually Reaper crashes to the desktop. I have tried many other synths and plugs and none does what my synth does. Malc is on it and I hope he finds the problem.

Most of the times when SM crashes on me it is because I have made some strange illegal connection and most of the times, if I can repeat it, I send the stuff to Malc. Sometimes i cant repeat it and that is worse i think. Makes it hard to fix.

I think SM is a very complex program with almost endless possibilities and that is why it is hard to find all the bugs and ways to crash it. Especially if your a 2 man crew working on it. What SM needs is more people working on it. But that might not happen. To hire people costs money. Best would be if a bigger company bought them up and cashed in some... but I doubt that will happen =( This is all very frustrating but I hope that things will get better. Even if they dont I will stick to SM since there is no other option for me. I really like this program even though it has its flaws. But hey. So do I 😉

aliasant · 8 Oct 2008

electrogear wrote: I found it was very laggy at one point, and I narrowed it down to some big multiplexers, which I replaced with big banks of selectors. This eliminated editing lag for me, but increased CPU somewhat (I *think* - although I could never quite be 100%).

I had the same. Thanks to Mike I to replaced the standard Matrix with a selector based one and everything works faster and better. if you havnt tried that maybe you should?

infuzion · 8 Oct 2008

Thanks everyone for verifying this, I thought I was either going mad, or being a cry baby.

electrogear wrote: ...Have you tried rolling back to the last version? (1.1.1)? This is the version I used to build the schematic, and after a while you kinda get to know what makes it crash and just have to avoid certain actions. I found it was very laggy at one point, and I narrowed it down to some big multiplexers, which I replaced with big banks of selectors.

I jumped on 1.1.2, since a few memory leaks & crashes have been reported to have been fixed. Sometimes, all I have to is open the said file in a fresh SM, & play 1 note, & SM will crash with no bug reporter. Not exactly what I'd call a stable program!

The project manager said the file was hard to edit due to lag/crashes also, but the exported VSTi hasn't crashed yet in Live5, which is good news. But that is only 1 in about 20 frequently used hosts.

I was wondering what all the Selectors were about; I was thinking they were Multiplexer workarounds.

Acrobat · 8 Oct 2008

electrogear wrote: Have you tried rolling back to the last version? (1.1.1)?

I am STILL at 1.1.1, my dear, that's the "right" version ATM. 😉

electrogear · 9 Oct 2008

Acrobat wrote: electrogear wrote: Have you tried rolling back to the last version? (1.1.1)?

I am STILL at 1.1.1, my dear, that's the "right" version ATM. 😉

Yes, it appears so.

@Infuzion - I have the same problems as you exactly. Crashing after load (when inputting a midi change). It even crashed as I was dragging an EQ node around. Roll back to 1.1.1, it was much more stable. You can always bring it back to the latest version for exporting to fix memory leak problems. In the meantime, hopefully Malc can get it sorted for the next release, or do a re-release of 1.1.2?

Cheers,

Mike

Tom7777 · 10 Oct 2008

Thing with SM is even though it is great when bugs get fixed i find a few versions down the line theres another big bug or it seems more unstable etc so it's fairly random rather than getting more and more stable as time goes by, hopefully one day i will be able to have fast loading cpu efficiant plugins and work happily in the app for hours at a time without problems, with SM i have come to expect crashes so now days i always check save backup just in case.

malc · 10 Oct 2008

Mike, can you send me an example that crashes so I can take a look? I've got some stuff from infuzion but it would be good to have something else, particularly if it can be easily crashed.

Dan, if you have something that crashes repeatably do send it my way. As you saw from my recent response to your email I could deal with all the schematics you sent through.

Nothing dramatic came up during the beta testing so I'm quite surprised you're finding such significant differences beteween 1.1.1 and 1.1.2. There were very few changes so it must be something simple and easy to track down if it only came in 1.1.2.

Tom7777 · 10 Oct 2008

Dan, if you have something that crashes repeatably do send it my way. As you saw from my recent response to your email I could deal with all the schematics you sent through.

Well as you know i usually send crashes to you with a osm when i can track them down 😉 The problem is i get random crashes all the time which is why i send the logs every now and then but i don't know if they help for the random stuff or not.

And yeah you sent workarounds but as i said in the email they were not my projects just ones i had found that went super slow, i sent those really in the hope that they might help you see what causes SM to get slow in some cases and maybe improve on that so they go faster and make the program faster etc.

Slowdown in SM is a big issue for me and why i don't work on large projects and never continued previous ones, it happens with building in general when projects reach a certain size i find and with other things like multiple text areas filled with array data even when nothings happening, then theres the toolbox which seems to take forever to load now but yeah im just hoping that, cpu and load times gets fixed then no doubt i will be using SM as much as i used too, atm i find it just can't handle some of the stuff i want to make.

electrogear · 10 Oct 2008

malc wrote: Mike, can you send me an example that crashes so I can take a look? I've got some stuff from infuzion but it would be good to have something else, particularly if it can be easily crashed.

Dan, if you have something that crashes repeatably do send it my way. As you saw from my recent response to your email I could deal with all the schematics you sent through.

Nothing dramatic came up during the beta testing so I'm quite surprised you're finding such significant differences beteween 1.1.1 and 1.1.2. There were very few changes so it must be something simple and easy to track down if it only came in 1.1.2.

Hi Malc,

I have been working for a month or so at a gas terminal (12 hour shifts, 7 days/week!) so I've had zero tiome for Synthmaker I'm afraid, otherwise I would have reported this during Beta.

I can not give you any crash reports whatsoever I'm afraid, as all crashes so far have not generated them, but I can tell you how to reproduce the crashes (I believe Infuzion has already sent you the .osm through). Just load up the .osm, activate the midi in, and play a Midi note. It will crash instantly. I've tried this on 2 systems and it does it every time without fail.

Other crash situations seems somewhat random. For example, I loaded the .osm, this time making sure I didn't touch any midi signals, but started dragging around one of the EQ nodes. Again, after a bit of playing around it crashed, and again, no crash report.

Cheers,

Mike

Eska · 10 Oct 2008

SM 1.1.2 is currently very stable for me but 2 months before I had a osm with a very similar behavior. I found a feedback-loop without a sample-delay and fixed it. Then the osm startet to crash after 10 to 30 minutes. After 2 weeks (!!) I found another feedback-loop without sample-delay... but with a multiplication to zero in between.

Acrobat · 10 Oct 2008

Eska wrote: SM 1.1.2 is currently very stable for me but 2 months before I had a osm with a very similar behavior. I found a feedback-loop without a sample-delay and fixed it. Then the osm startet to crash after 10 to 30 minutes. After 2 weeks (!!) I found another feedback-loop without sample-delay... but with a multiplication to zero in between.

Sorry, Eska, I don't understand why a feedback loop causes crashes. I usually notice that situation generates 100% CPU use and very slow motion with the mouse and such, but it never caused crashes here. Unless I insist keeping the feedback that way but that's crazyness, because your workflow will be ridiculously slow. So for this reason I think that my crashes were probably of other nature when I was using SM version 1.1. Now that I use 1.1.1 I don't have any crash at all. And never tried 1.1.2 still.

Tom7777 · 11 Oct 2008

Sorry, Eska, I don't understand why a feedback loop causes crashes.

I have had crashes in the past with stuff like that but havent really done that recently other than streams, i think sometimes it can create a endless event and if theres denormals etc in the path that might cause big problems but im not sure but i remember at one time feedback had problems, seems much better with audio now but not sure about other data types.

infuzion · 11 Oct 2008

Malc said in an email to specify what I did exactly... so it seems best we remember all we did before a crash, then send the OSM & steps taken right away.

infuzion · 2 Nov 2008

Any progress on this please? I just got another crash editing the file I sent you. Actually, I never got to edit it; after having it open for 5 minutes, looking inside a few modules, then copy/pasting a Stereo Amp within a OSC to an empty OSM, going back to the big file, SM noreport-crash when I tried to go back to the newly pasted OSM.

So as it stands, it will take me atleast 20% more time to edit this huge OSM, which I'm forced to charge the client, or talk him into looking for another platform.

malc · 4 Nov 2008

I'm pretty sure I have the 'open and play a note' crash sorted now. This combined with trying to sort the clicking issues that some people have been experiencing has led to some fairly low level restructuring.

aliasant · 4 Nov 2008

malc wrote: I'm pretty sure I have the 'open and play a note' crash sorted now. This combined with trying to sort the clicking issues that some people have been experiencing has led to some fairly low level restructuring.

So this is good news right?

matti · 4 Nov 2008

Hmm this all sounds very strange. I've reported many bugs myself but never had anything that i couldn't recognize and or get around somehow.

My tips: Finding the problem spot starts from understanding the schematic properly. Keeping everything modularized and organized helps alot in this. So don't forget about the basic principles of programming when connecting the dots. Even tho it's graphical it's still programming. And ofcourse, keeping things simple(as possible) avoids most of the problems to begin with.

The biggest problem at the moment in SM for me is that the processing of green data can't be stopped. There should be a failsafe button somewhere that would kill all processing on them. Really annoying to forget one float-primitive connected to something and making a trivial two second calculation take over 15 minutes. Some might consider this a "crash" too..

Other than that I've had no trouble with SM lately at all. I've created synths, eq's, distortions, my own fft implementations(to learn the theory better), convolutions, reverbs, delays, sysex editors and loaders, an automatic sampler(a tool to sample sounds out of hw romplers streight to separate files on disk) and lot's of usefull little tools that are now essential to my studio work. SM is simply the best music tool i've ever bought! 😍

aliasant · 4 Nov 2008

matti wrote: Hmm this all sounds very strange. I've reported many bugs myself but never had anything that i couldn't recognize and or get around somehow.

My tips: Finding the problem spot starts from understanding the schematic properly. Keeping everything modularized and organized helps alot in this. So don't forget about the basic principles of programming when connecting the dots. Even tho it's graphical it's still programming. And ofcourse, keeping things simple(as possible) avoids most of the problems to begin with.

The biggest problem at the moment in SM for me is that the processing of green data can't be stopped. There should be a failsafe button somewhere that would kill all processing on them. Really annoying to forget one float-primitive connected to something and making a trivial two second calculation take over 15 minutes. Some might consider this a "crash" too..

Other than that I've had no trouble with SM lately at all. I've created synths, eq's, distortions, my own fft implementations(to learn the theory better), convolutions, reverbs, delays, sysex editors and loaders, an automatic sampler(a tool to sample sounds out of hw romplers streight to separate files on disk) and lot's of usefull little tools that are now essential to my studio work. SM is simply the best music tool i've ever bought! 😍

Gotta agree. I have had almost no crashes since 1.12 Wroks quite well. Sure there are bugs and bad code and what not but not that many crashes. And most of them have been because I did something stupid.

exonerate · 4 Nov 2008

Yes SM is very stable for me, but then it always has been, although there have been a few times I hit upon guaranteed crash situations, but these have normally been quite obscure crashes, within a very narrow set of circumstances.

The most crashes I've had with SM have been with the parser components, and feedback loops ( in the green domain).

In fact here's a guaranteed crash situation for you, add a green float add to an empty schematic then connect that to a float component, now take the output of the float add and connect that to it's input, crash.

Now I'm not sure if anything should be done internally to SMs code to prevent such crashes, it can be avoid quite easily by using a sample and hold in between the feedback loop (which is the correct way of doing such a thing), so I see it as more of a noob mistake than something SM should fix, although I'm not sure really maybe SM should detect the loop and add it's own sample and hold.

But anyway doing noobie things like that, and not knowing how to use the parser correctly will usually result in a crash for me.

Cheers 😉

Exo

bootsy · 4 Nov 2008

Almost no crashes here, nothing to complain. But I'm still annoyed that there are known issues in compiled VSTs for such a long time, e.g. loading times or disappering GUIs and plug-in removal crashes in certain hosts and configurations. In each and every beta test I get such reports and complains.

infuzion · 4 Nov 2008

hmmm, have you guys done alot of copy & pasting of modules that contain modules please? If I do that, esp quite a few times, I'll end up with a crash.

Acrobat · 4 Nov 2008

infuzion wrote: hmmm, have you guys done alot of copy & pasting of modules that contain modules please? If I do that, esp quite a few times, I'll end up with a crash.

Although I use the quite solid 1.1.1, yes, C&P nested modules can end in crashes still. Anyway the more complicated stuff yo're coping, easier it would crash.

Some primitives seem to raise the probabilty but I can't point any in particular... one I'm pretty sure it's the MONO2POLY, that MEM write is quite dangerous... 🙂

infuzion · 5 Nov 2008

related request: Option: Literal (debugging) Activity Log

electrogear · 9 Nov 2008

I am getting quite frequent crashes too. Silly one happened just now - I copied & pasted a mono4 multiplier and it crashed with no report.

infuzion · 10 Nov 2008

electrogear wrote: ...I copied & pasted a mono4 multiplier and it crashed with no report.

hmmm, the big OSM I sent to Malc has a few Pack4/Unpack4 in it...

phertel · 12 Nov 2008

Hello @all I have a many chrashes to! Especially when I change the waveform in my LFO to sinus. When I testing my Project and I do so when the sound is not fade anway then SM crashes. If I made a VSTi and I test it in FL then FL crashes to. In Last time SM 1.1.2 don't make a report. 😮 It's hard to work with SM!!!!!

greatings Peter

PS: Who said SM is stable? 😕 Stable is anything others! Here my Project. It's a very early not finised project. It's a little Buzzer now! 😉

Tom7777 · 13 Nov 2008

PS: Who said SM is stable?

Don't know, i guess the people that complain at the few that actually mention it's not, until they run into problems themselves hehe 😉 I have been getting crashes constantly for a large percentage of the time i have been using SM myself, im taking a break from it for a while myself and will leave it up to others to find the bugs for a bit 😀

phertel · 14 Nov 2008

Oh the problem with Copy and paste into the Modulcontainer I have allso. If I made it sometimes then SM crashs. 🙁 The most i must do is saving. I can't work without the Autosavingmode. 😠 The other problem is that sometimes the SM is hanging around. Then I must delete them with my Windows Taskmanager! 😝 Oh CrashMaker ... ehhm ... SynthMaker, what can I do?

greatings Peter Peter

infuzion · 14 Nov 2008

I hope you're sending example OSMs & steps taken to make the crash to [email removed]?

phertel · 15 Nov 2008

First before I send any thing I must collect some errors. There are more then crashes only. Now there was an other phenomenom to. I worked a little bit on to my Synth. Now I want to test a new Module. I klick with the Mouse into the Modul GUI and the Cursor disappeard. Now I can work in a mysterios blinde mode of SM. 😉 The workaround is when I copy this Module, delete the original Module in SM and at last paste the same Module back in to SM. Now this problem disappeard. This are problems I can't reproduce continiuous. It comes up when I often change my GUI and move components around my own Applicaton-Desktop.

Ok, I will write now a EMail with all my misery.

greatings Peter

infuzion · 16 Nov 2008

phertel wrote: Ok, I will write now a EMail with all my misery.

Sounds like you need a >hug< Peter 🙂

phertel · 16 Nov 2008

THX @ Infuzion for sincere condulence 😉 But I'm strong and I will fight continuing! In the hope I find my Peace with SM! 😀

greatings Peter

phertel · 17 Nov 2008

To day Malcom has wrote me. He has a guess, he wrote. I'm tight what's comming arround!

greatings Peter

infuzion · 28 Nov 2008

Any luck with this please?

I found a repeatable crash I think that is related; when I would use this reduced code in an ASM for an envelope, I would replace everything inside the Gate but the Envelope Control. SM would crash sometimes when I copy-pasted those two (ASM+Env Control) connected elsewhere, or it would crash when connecting the entire involved envelope module up to either of the Cycle Tools.

Let me know if you want the files.

infuzion · 28 Nov 2008

I think I found the common issue: loopbacks.

infuzion · 29 Nov 2008

...& copy/pasting text into ASM & copy/pasting the ASM primitive.

malc · 29 Nov 2008

Sure, send me any files you have that cause crashes.

From the previous ones you sent I managed to sort a couple of problems. In particular, the one that crashed when you play a note should be resolved in the next update.

Whilst the crashes you're describing with the Assembler component don't sound like they are related to the actual asm you're using I just wanted to take the opportunity to make sure that you all know that you do have to be careful 🙂

Anyway, will take a look. Thanks.

Tom7777 · 1 Dec 2008

Attention ASM-FU experts... Interpolated Delay?

download/file.php?id=993

1 - zoom out so you can see the whole area

2 - go into 'AUDIO OUT YES VOl VELOCITY' and copy 'LRVolume' then go to the previous level

3 - Select everything and hit the delete key

4 - SM crash

aliasant · 1 Dec 2008

Tom7777 wrote: [old link]

[old link]

1 - zoom out so you can see the whole area

2 - go into 'AUDIO OUT YES VOl VELOCITY' and copy 'LRVolume' then go to the previous level

3 - Select everything and hit the delete key

4 - SM crash

Great report. Yes. I can confirm. Crashes.

malc · 2 Dec 2008

Thanks Dan, crashes here too so I should be able to sort it.

Incidentally I only needed to do step 3 and it crashed.

infuzion · 5 Dec 2008

malc wrote: From the previous ones you sent I managed to sort a couple of problems. In particular, the one that crashed when you play a note should be resolved in the next update.

When will the next update be please? This is putting a damper on the project I'm working on... sometimes I can reset the audio-out to avoid this crash, sometimes the audio-out resetting causes another crash.... lost a hour of work already from this. 😠 😝

infuzion · 6 Dec 2008

Update: Malc said that he's gotten rid of some of these crash scenarios (on first note opening a new file, pasting ASM), so things are looking brighter for the future.

Tom7777 · 8 Dec 2008

Oversampling Toolkit

download/file.php?id=180

1 - Load OSM 2 - Delete both blue wires going to monitoring and also the 2 Scopes 3 - Go into Osc, delete both combiners 4 - rewire 1X SAW and 2X Downsampling Polyphase IIR to outputs 5 - SM Crash

malc · 12 Dec 2008

Outstanding spot Dan!

It seems that Mono To Float and Mono To Graph comps are not being properly detached from the schematic when they are deleted. It's fine if you delete the components themselves but if you delete a parent module they don't get removed correctly.

This is very likely to cause memory errors which could result in crashes occurring several edits down the line from the action that caused the problem, adding to the confusion as to the actual cause. Once a module containing one of these components has been deleted, any subsequent action that causes a recompile of the audio code could trigger a crash (copy and paste, creating a link, dragging a component from the toolbox, undo/redo...)

Thanks for posting - these are exactly the kinds of reports that we need.

Tom7777 · 12 Dec 2008

No problem 🙂

Andrew J · 13 Dec 2008

Eureka! Methinks this could possibly be linked to a number of reported issues with large schematics - at least it makes sense of some of the issues I had some time ago.

Acrobat · 13 Dec 2008

malc wrote: It's fine if you delete the components themselves but if you delete a parent module they don't get removed correctly.

YYYesssss! Focalized. Ultraconfirmed 😉

infuzion · 14 Dec 2008

Looking forward to a new beta soon, with this & the buss fixes. 😉

MichaelBenjamin · 17 Dec 2008

btw, if things do not get properly deleted.. if i use oscilloscopes and analysers, and delete the whole module after the checking, does the schematic fill up with ghost combiners and mono2 floats that keep running even after a save and restart? i just had this impression, as a schematic starts to use more and more cpu, the more i check with polystream analysers. it would be quite bad if these ghostmodules propagate even in an exported vst.

aliasant · 17 Dec 2008

MichaelBenjamin wrote: btw, if things do not get properly deleted.. if i use oscilloscopes and analysers, and delete the whole module after the checking, does the schematic fill up with ghost combiners and mono2 floats that keep running even after a save and restart? i just had this impression, as a schematic starts to use more and more cpu, the more i check with polystream analysers. it would be quite bad if these ghostmodules propagate even in an exported vst.

I have the exact same question so I wont ask it.... 😉

malc · 18 Dec 2008

It's more likely you'd get a crash before you saw any impact on performance. If you managed to avoid a crash then when you reload everything would be fine (exporting to VST would be fine too).