SoundDiver - short freeze-up after any slider change

[aanon]

I'm on a Windows 7 64 bit system.

I'm using SoundDiver 3.0.5 to edit programs on my Triton MOSS card. I tried a bunch of software editors and overall I like SoundDiver the best.

However, there is one issue that is making it much harder to enjoy using: after I change any parameter with a slider in the SoundDiver editor, the program momentarily freezes and I have to wait a while, watching the Windows spinning blue ring, until it comes back to normal.

In more detail:

* if I change a parameter by typing the value in, there is no problem
* if I change a parameter by using an on-screen slider in SoundDiver, the MIDI messages are sent out immediately (verified by watching the stream with MIDI-OX and also by hearing my synth respond), however the program freezes up for a short time
* if I quickly move a slider just a short distance, the freeze time is not a problem (say, a second or less)
* if I move a slider a longer distance and/or take more time doing it, the freeze time can be substantial (10 seconds or more)
* this prevents me freely moving sliders to explore the way the synth will respond (which is a big part of the fun, IMO)

Has anyone come up against this problem with SoundDiver? Any tips to avoid such issues?

Any advice would be much appreciated.

Aanon

[desmond]

It's probably transmitting the slider value via MIDI.

If you enable "Hold transmission", so no MIDI is sent, do you still get the same hang when adjusting parameters?

[aanon]

It's probably transmitting the slider value via MIDI.

If you enable "Hold transmission", so no MIDI is sent, do you still get the same hang when adjusting parameters?

Hi Desmond,

Thank you for your input.

I tested the with "Hold transmission" enabled. The same issue still occurs (after moving a slider I need to wait a while, watching the spinning blue circle, before the SoundDiver program unfreezes).

I should also note that I have tested several other editors including Midi Quest and there is no such freezing up experienced when using those programs.

In normal use, the slider value should be transmitted via MIDI. And it is, without any delay. I can see the messages go out immediately by using MIDI monitor in MIDI-OX. The freeze that happens subsequently seems to be something happening strictly within the SoundDiver program itself (perhaps updating its working memory, or something similar).

Regards,

Aanon

[desmond]

I tested the with "Hold transmission" enabled. The same issue still occurs (after moving a slider I need to wait a while, watching the spinning blue circle, before the SoundDiver program unfreezes).

Ok - worth a try.

I should also note that I have tested several other editors including Midi Quest and there is no such freezing up experienced when using those programs.

Yep, I know, SD is old and crusty these days.

In normal use, the slider value should be transmitted via MIDI. And it is, without any delay. I can see the messages go out immediately by using MIDI monitor in MIDI-OX. The freeze that happens subsequently seems to be something happening strictly within the SoundDiver program itself (perhaps updating its working memory, or something similar).

Does this happen with every device, or is it only certain devices? You're correct in that sometimes the software has to do some work to store or reorganise data, depending on how the device works.

I'll have a look to see if it behaves the same here for the Triton MOSS boards...

[aanon]

Hi again Desmond,

I have to say, I really appreciate your responses. I really thought it was a long shot to find somebody able to help with SoundDiver!

I've done a few more experiments and found that if go into the MOSS patch editor in SoundDiver and then I physically disconnect the MIDI output cable from the Triton, I can edit the patch to my heart's content and never experience the freezing issue.

Of course, this doesn't allow for requesting banks and patches from the Triton -- but it's a good clue I think!

Looking more closely at the MIDI monitor within SoundDiver when the Triton MIDI output is connected, it appears that when SoundDiver sends a parameter change, the Triton responds with a couple of short SYSEX messages after a delay.

When a longer string of parameter changes is sent, the Triton responds with a longer string of its SYSEX messages.

It appears that SoundDiver is getting bogged down somehow by these incoming messages.

Hope the image attachments work ok!

[meatballfulton]

Many synths output sysex strings when parameters are changed, you probably are aware of this already. If the Triton allows blocking transmitting sysex, then you could simply enable that when using SoundDiver, then disenable it when done with your edits. Or disconnect the MIDI cable if that is easier

[desmond]

Easier still is to change the MIDI input port for the Korg Triton in SD's inspector to a different MIDI input port temporarily, so it will ignore MIDI input on the Triton's actual MIDI port.

[aanon]

Thanks again for all the helpful suggestions.

I'm going to mute the sysex coming back from the Triton -- when not needed-- using my MOTU MTP AV for the time being.

Interestingly, even changing the MIDI input port for the device within SoundDiver doesn't stop the sysex messages coming from the Triton from freezing the program.

Anyway, with the current solution it's only a small inconvenience and I'm very happy to be back exploring what the Triton MOSS card can do.

All the best,

Aanon

[blueknob]

I use SD a lot, it's a pain. I've used it on Win98se to XP as that's my last OS by choice, and it's far from perfect. I've also used it on Mac OS7,9 and Tiger. It's different (errors) on each OS.

It's fundamentally not designed to work on anything XP and beyond! Back in the day it's creator gave me some little pointers. Meaning it will always be wonky in some way. emagic had to write (in code) their very own screen buffer, nothing to do with Windows and that's where many problems come from. The spec for Windows kept moving, emagic couldn't keep up, can't be expected to.

I've written a number of Adaptations for SD, latterly in XP and it's just a real PITA, messes the screen up, boxes don't work and crashes a lot. The Manual is Germalish (just awful to follow). Having said all that SoundDiver is a great concept, when it works it's really good and why I stick with it.

My guess is, SD don't work good on 64bit anything. Then I'd ponder a buffer size, there might be a setting, although there's so few tweaks.
Then I'd make a simple "test" Adaptation, try and find what in the system causes the problem.It could be something really silly if you get that far.
Maybe load in a different Adaptation for another synth, it's possible to send midi without having the real synth attached.

As I write this I'm having that..hmm.. I seem to remember something like this happening to me.. I changed a parameter.. seem unrelated but it worked.

[blueknob]

Whilst making a brew (of tea) I remember! I've had it where, the synth was connected MIDI in and out and I wasn't aware or expecting there was a Thru active in the chain. So when moving a slider SD was sending a midi string for every increment, only to receive a message instantly in return which it processed (hence the delay). SD will work open loop.

I'm sure you (OP) have already tried this kind of thing.

[aanon]

Thanks Blueknob,

It would be great if there was a setting somewhere that might solve the issue altogether.

I had a look for "soft thru" options on the Triton but didn't see anything on the screens or in the manual. My suspicion is that this isn't a cause here, given that I don't see any of the original data echoed back.

Maybe one rainy day I'll try setting it up with an older PC, as i have a few nearly-vintage boxes around the place.

All the best,

Aanon