search

pierreguillot / Camomile

An audio plugin with Pure Data embedded that allows to load and to control patches
GNU General Public License v3.0
905 stars 64 forks source link

Unable to send OSC information from one Camomile instance to another #241

Open aviloff opened 3 years ago

aviloff commented 3 years ago

When one active plugin has a [netsend -u -b] and the other has [netreceive -u -b] on the same port, the receiving plugin writes the following in the console:

netreceive: listen failed: Address already in use (48)

Thus sending data becomes impossible.

This does not happen when two PureData patches are running simultaneously.

macOS 10.15.7 Camomile 1.0.8 beta 4 puredata 0.51.1 Reaper 6.21 VST3 plugin versions

pierreguillot commented 3 years ago

Can you share patches so I can test?

aviloff commented 3 years ago

I was checking with minimal working examples, and it worked.

However when I load my desired plugin, after 3-4 Reaper restarts it either starts to say that listen failed: Address already in use (48) or Reaper stops receiving OSC messages from the plugin. Only a full restart helps in this case.

The desired plugin is in the plugins folder of this repository The minimal working examples are in the test folder of the same repository

pierreguillot commented 3 years ago

I tried the patches from the test folder directly in Pd and they don't work as expected I guess.

On Pd 0.50-2, sending I send a message via [netsend] generates the error: recv: Connection refused (61) netsend: Bad file descriptor (9)

On Pd 0.51-4, sending I send a message via [netsend] doesn't do anything. I can't know if there is a problem with [netsend] or [netreceive].

By the way, I think, the list should be prepended with the symbol "send" before sending it via [netsend].

I tested on BigSur 11.1, I will test with an older macOS later. This problem might be related to the way Pd manages UPD messages on macOS (it seems to work properly with TCP messages) but further investigation is necessary. Camomile 1.0.8 beta 4 is compiled against Pd 0.51-4, can you test the patches with this Pd version?

aviloff commented 3 years ago

I have installed PD 0.51.4, and rechecked on 10.15.7, the test plugins are working.

Screenshot 2021-02-23 at 18 19 37

According to oscformat-help.pd:

"send" is optional for lists as of Pd 0.51

But I made the proposed modification just in case, and it worked the same way.

But for the ChannelChecker plugin, that receives, processes and resends OSC messages, after a few DAW restarts I started getting the message

netreceive: listen failed: Address already in use (48)

image

This plugin listens on port 15200 unlike the test plugins that use port 15000.

Could it be that libpd or Camomile do not properly close the UDP connection when the DAW project is closed?

pierreguillot commented 3 years ago

Could it be that libpd or Camomile do not properly close the UDP connection when the DAW project is closed?

That might be possible and I'm not sure of the multi-instance/thread support of the net objects. I'll check the code and it might be helpful to directly ask on the Pd list also.

pierreguillot commented 3 years ago

Can you try this version and tell me if it solves the problem? If so, I'll try to see with the Pd devs if it can be integrated into Pd itself or if they know another way of fixing this issue. Thank you.

pierreguillot commented 3 years ago

I discussed with Pd dev on the mailing list and my solution is not appropriate.

Now, I know a bit more about sockets and how net objects work. I think that perhaps the problem is related to the way you use net objects. Are you sure that only 1 instance of the patch is loaded at a time? And you should not have the patch opened in Pd either. Because you can have only 1 [netreceive] object (or any socket from another application) listening on the same address and the same port, that's a limitation.

If you want several applications, patches, or plugins to listen from the same address and port, you should use 1 [netreceive] object and dispatch the information manually or use the multicast option on [netreceive] (but I don't know yet how it works...)

aviloff commented 3 years ago

I have been lightly testing the plugin with the new Camomile build and never yet got the message "address is in use", that I was getting before. There was a problem with Reaper stopping to receive OSC messages, but that was after I force quit it, so guess it's and a Reaper issue from now on.

I was always checking that only one active application receives on a given port, so PureData was not active when the plugin was active.

I don't know what you changed in this special build, of course, but possibly it's a good idea to keep some "precaution" changes, as the problem did not reappear so far.

pierreguillot commented 3 years ago

The "new Camomile build" is the one v1.0.8-beta4 or the one I linked in this issue? If this is the one I linked in this issue, you should not rely on it because I will not keep the changes. If this is v1.0.8-beta4 or an older version, I guess it means that the problem is fixed and we can close the issue, isn't it?

aviloff commented 3 years ago

I have been testing these days. This concept of sending OSC messages back and forth between application requires a lot of debugging, as many applications are working at the same time. Reaper is proving not to work stably enough with OSC messages sent from Camomile, then the reason for this on macOS Catalina is currently difficult to trace. I would suggest not to close the issue now, though I also understand that some problems may not be directly related to Camomile. I would still like to keep referring and posting solutions on this thread, as networking is one of the unique opportunities that Camomile+PureData provide in comparison to many other plugins.