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.

Sign up for GitHub

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

Jump to bottom

scsynth OSC packet size in NRT mode #61

Closed
jleben opened this issue May 6, 2012 · 5 comments
Closed

scsynth OSC packet size in NRT mode #61

jleben opened this issue May 6, 2012 · 5 comments
Labels
bug Issues that relate to unexpected/unwanted behavior. Don't use for PRs. retest
Milestone
3.8

Comments

@jleben
Copy link
Member

jleben commented May 6, 2012

[Issue migrated from SourceForge | ID: 1970340 | Submitted by 'sciss']
[http://sourceforge.net/support/tracker.php?aid=1970340]

scsynth's OSC packet size differs from realtime and NRT mode, in realtime i think it's 64K(?) and in NRT just 8K(?). that produces problems in porting realtime code to NRT equivalents, particularly with using /d_recv to transfer synthdefs. The packet size should be increased in NRT to match the realtime size.
@telephon
Copy link
Member

Also Rohan mentioned this recently.

We have three different situations:

  1. sending packets via udp (size limit: 65535 bytes)
  2. sending packets via tcp (size limit: 65535 bytes, too?)
  3. accumulating a file for NRT synthesis (size limit: none?)

–> 2. surprises me, because I thought that size wouldn't matter in tcp
compare: http://stackoverflow.com/questions/2613734/maximum-packet-size-for-a-tcp-connection.

There are different places in the system where packet sizes are checked, some in the class library, some in the lang sources.
E.g. one is in NetAddr:sendClumpedBundles.

Once we know all the correct size limits, and where they currently are applied, we can fix this correctly.

@scztt scztt added this to the 3.7 milestone Apr 17, 2015
@scztt
Copy link
Contributor

scztt commented Apr 17, 2015

Someone want to look and see if this is an easy issue (meaning - changing a constant somewhere :) ) to fix for 3.7?

@davidgranstrom
Copy link
Contributor

Maybe this issue is obsolete now since #714 was merged?

@scztt scztt added the retest label Jun 28, 2015
@crucialfelix crucialfelix modified the milestones: 3.7.x, 3.8 Mar 14, 2016
@vivid-synth
Copy link
Member

Yup, this looks like a duplicate of #714

@joslloand joslloand mentioned this issue Jul 5, 2016
Closed
@vivid-synth
Copy link
Member

As this looks like a duplicate of #714 , can we close?

@nhthn nhthn closed this as completed Aug 1, 2016
mossheim pushed a commit that referenced this issue Aug 24, 2020
@LFSaw
Merge pull request #61 from novadeviator/patch-1
f356a48 
added nova.deviator.si blog
elgiano added a commit to elgiano/supercollider that referenced this issue Nov 8, 2020
@elgiano
sclang: AnalogOut and DigitalOut return 0.0
4fa05c5 
fixes an issue with Function::play. For UGens without any output, such 
as AnalogOut and DigitalOut, returning 0.0 prevents the creation of a 
wrapping Out UGen, which in turn was seen messing with poll rates in 
Bela's issue supercollider#61.
elgiano added a commit to elgiano/supercollider that referenced this issue Nov 8, 2020
@elgiano
sclang: AnalogOut and DigitalOut return 0.0
7dbba9b 
fixes an issue with Function::play. For UGens without any output, such 
as AnalogOut and DigitalOut, returning 0.0 prevents the creation of a 
wrapping Out UGen, which in turn was seen messing with poll rates in 
Bela's issue supercollider#61.
elgiano added a commit to elgiano/supercollider that referenced this issue Nov 28, 2020
@elgiano @giuliomoro
sclang: AnalogOut and DigitalOut return 0.0
313f28a 
fixes an issue with Function::play. For UGens without any output, such 
as AnalogOut and DigitalOut, returning 0.0 prevents the creation of a 
wrapping Out UGen, which in turn was seen messing with poll rates in 
Bela's issue supercollider#61.
elgiano added a commit to elgiano/supercollider that referenced this issue Dec 2, 2020
@elgiano @giuliomoro
sclang: AnalogOut and DigitalOut return 0.0
eba7a53 
fixes an issue with Function::play. For UGens without any output, such 
as AnalogOut and DigitalOut, returning 0.0 prevents the creation of a 
wrapping Out UGen, which in turn was seen messing with poll rates in 
Bela's issue supercollider#61.
@Lispilo Lispilo mentioned this issue Nov 13, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Issues that relate to unexpected/unwanted behavior. Don't use for PRs. retest
Projects
None yet
Milestone
3.8
Development

No branches or pull requests
7 participants
@scztt @jleben @crucialfelix @davidgranstrom @nhthn @telephon @vivid-synth