Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Oscpack 1.1.0 PR #3210

Merged
merged 12 commits into from
Oct 29, 2014
Merged

Oscpack 1.1.0 PR #3210

merged 12 commits into from
Oct 29, 2014

Conversation

ofTheo
Copy link
Member

@ofTheo ofTheo commented Sep 9, 2014

This PR continues #2513

Split into two commits.

  • oscpack1.1.0 integration
  • patches to oscpack to allow broadcast and port reuse to work correctly ( see WIP: Upgrade oscpack to 1.1.0 #2513 ). this is so @RossBencina can see changes needed for potential upstream patch to oscpack. Here is the diff for the oscpack changes - 0b42a71

 - function to set udp buffer sizes - as discussed in #3106 

@ofTheo
Copy link
Member Author

ofTheo commented Sep 9, 2014

@RossBencina - you can see the configurable buffer code in the last three commits. By default it doesn't do anything different to the 1.1.0 version.

If you call UdpSocket::SetUdpBufferSize(65355); before opening sockets it sets the global socket variable for all osc sockets to use that buffer size.

Tested with openFrameworks it behaves as expected with the image / blob sending example, but now allows the user to choose to increase the buffer size to whatever amount they want.

Feel free to pull this in, or request changes. It could also be set to 65355 by default fairly easily ( 2^16 ), but I didn't want to change the default behavior, so will leave that up to you.

@bilderbuchi
Copy link
Member

thanks for taking this over! I see you have not renamed some of the windows files to disambiguate the filenames, see 9c103e4. This was necessary previously for OF (I think on VS?) so that the build process doesn't get confused, maybe it's not necessary anymore?
Also, maybe review the rest of the commit list in #2513, I think an up-to-date addon_config.mk (see aa9caa2) will be necessary, as well as this one: c30c294

@ofTheo
Copy link
Member Author

ofTheo commented Sep 9, 2014

@bilderbuchi - yes meant to go through and pull in the remaining stuff.
my goal is to change oscpack as little as possible, so was hoping that we wouldn't need to rename the files.

@bilderbuchi
Copy link
Member

yes, that's my hope, too!

@ofTheo
Copy link
Member Author

ofTheo commented Sep 14, 2014

Okay - just tested this with the PG.
The addons_config file handles excluding the win32 / posix files well so no need to rename.

Think this is good to merge.

@bilderbuchi
Copy link
Member

I think the problem was never with the makefile-based approach, but with IDE projects, i.e. xcode/codeblocks/VS... not sure though as I've never personally experienced that.

@arturoc
Copy link
Member

arturoc commented Sep 14, 2014

@bilderbuchi the PG uses addons_config.mk too so it should be ok

@ofTheo
Copy link
Member Author

ofTheo commented Sep 14, 2014

yeah - I just tested it with the PG - it works great. the addons_config system is really helpful!

@bilderbuchi
Copy link
Member

ah, great, didn't realize that Arturo!

@ofTheo
Copy link
Member Author

ofTheo commented Sep 15, 2014

okay going to merge this if there are no objections

@pizthewiz
Copy link
Member

Yay new oscpack!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants