"Create New Song" dialogue freezes

[dhj]

@Markus

nd gloabl rackspace message transmitters/handlers which worked fine

You were probably using explicit port numbers rather than the default defined in Options

[dhj]

@Markus

Thanks so much

Actually, @djogon deserves the credit – he already suspected it was an OSC settings problem as that’s the only thing different between different instances of GP

[Markus]

@dhj

Actually, @djogon deserves the credit – he already suspected it was an OSC settings problem as that’s the only thing different between different instances of GP

Yes great idea @djogon and in general a great community here!

[djogon]

@Markus - when I suggested earlier that you disable your WiFi and UNPLUG your hard network cable - this is what I had in mind, but of course, if you used 127.0.0.1 with same ports as your in and out IP address that would not have made a difference.

Otherwise - that suggestion should have worked and revealed the issue.

[Markus]

@djogon Yes indeed. Unfortunately when I started learning scripting some month ago I was not aware GP uses this OSC Connections also internally at some point. I felt free to configure OSC cleint/server IP settings just according to my needs in the local and global rack space scripts. And since my communication was unidirectional (local rackspace instructs global rackspace to load an appropiate GP User Preset on each VST plugin without returning any response/acknowledge), I could use same port number for local loopback without the risk of getting loops.

But may be this could be prevented/forbidden by GP in future releases because of loops in bidirectional communication.

[dhj]

@Markus

I was not aware GP uses this OSC Connections also internally at some point

It doesn’t by itself! GP can send OSC messages out and it can respond to incoming OSC messages.

But if you connect an “output” directly back to an “input”, you will create a feedback look, just as if you hold a microphone close to a speaker that’s rendering whatever comes into the microphone.

We will have to see how much we can do to protect against this.

[Markus]

@dhj

But if you connect an “output” directly back to an “input”, you will create a feedback look, just as if you hold a microphone close to a speaker that’s rendering whatever comes into the microphone.

No, not if communication is unidirectional which means that IP endpoint sends a mesasge to himself but does not repond to this message where we have just a single “reply to sender” but no endless loop causing any issues.This exactly was the use case in my scripts. This is like a singer get’s his own voice back to his own ears via in ear monitroing but not back to his microphone because there is no speaker next to him. At least if OSC ist UDP based. may be TCP would be another story.

But since GP can not 100% know how this OSC config is used may be it’s good to block this.

[dhj]

@Markus

No, not if communication is unidirectional

GP will often respond to incoming requests from remote devices, for example, if you have a tablet that sends a message to GP to switch songs, GP will send back information after switching so that your tablet can update its display.

[Markus]

Yes I see, and this was something I was not aware of right from the beginning of my learning curve.

I often hear product managers saing “let’s put ourselfes in our customers shoes”. So I just try to communicate all what I have been doing and thinking in order to help preventing other custormers from running into the same issue.

But apart from that, excellent support, highly professional and fast!! Thank you so much!

[dhj]

@Markus

So I just try to communicate all what I have been doing and thinking in order to help preventing other custormers from running into the same issue.

Oh sure…and (a) we appreciate it and (b) we will add in that check. It’s just that it’s very unusual for this scenario to occur