removing "/" safeguards from OSCAddressPattern
jcurtis-cc opened this issue · 12 comments
jcurtis-cc commented
Hi Devin,
New to Swift, but loving SwiftOSC.
I've got an OSC server inside an app that is already written to parse specific OSC Address paths that don't include the opening "/" character.
I can send messages using other OSC frameworks (oscP5, ofxOSC, MaxMSP etc) without the opening slash - and the server successfully parses these messages. Rebuilding this server from source and altering the parser isn't feasible.
I'd like to be able to use SwiftOSC, but can't seem to successfully send any messages after changing the OSCAddressPattern to remove the opening slash "/"
Having a dig through OSCAddressPattern.swift I think I can see that it's probably returning false when the opening slash is removed. Can this be overridden safely?
Commenting out this feels hacky.. but works.
if address.first != "/" { return false }
jcurtis-cc commented
Actually, commenting out these lines only worked in the OSCTest example.
In the project I'm using where SwiftOSC was installed via CocoaPods, commenting out these lines doesn't work.
Is there an easy fix?
devinroth commented
Should still work but you need to rebuild the framework.
The leading “/“ is apart required by the OSC spec. I highly suspect the other programs are added it in if not done by the user. It makes me wonder what would happen if you start with “//“ since one and two mean different things.
That being said couldn’t you just append a “/“ at the beginning?
… On Nov 21, 2018, at 10:40 PM, Jay Curtis ***@***.***> wrote:
Actually, commenting out these lines only worked in the OSCTest example.
In the project I'm using where SwiftOSC was installed via CocoaPods, commenting out these lines doesn't work.
Is there an easy fix?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
devinroth commented
Sorry wrong button.
devinroth commented
It will be safer if you change to the following.
if address.first != "/" {
self.string = "/" + address
}
Haven't tested but it should work. The will not work without the leading "/" so this way you make it optional to add and add it if it doesn't exist.
jcurtis-cc commented
Hi Devin,
Thanks for the speedy response.
Rebuilding the framework didn't work for the Cocoapods import and threw an error re: editing privileges.
I've tested OSC frameworks (oscP5 (processing), ofxOSC (openFrameworks), MaxMSP) and none of these are prepending their OSC messages with a leading slash.
Would a rebuild for cocoapods making your leading slash be optional be possible?
Would help people make SwiftOSC clients that can actually communicate with servers using the standard in the above frameworks and where rebuilding OSC server sources isn't possible
… On 23 Nov 2018, at 01:24, devinroth ***@***.***> wrote:
Should still work but you need to rebuild the framework.
The leading “/“ is apart required by the OSC spec. I highly suspect the other programs are added it in if not done by the user. It makes me wonder what would happen if you start with “//“ since one and two mean different things.
That being said couldn’t of just append a “/“ at the beginning?
> On Nov 21, 2018, at 10:40 PM, Jay Curtis ***@***.***> wrote:
>
> Actually, commenting out these lines only worked in the OSCTest example.
>
> In the project I'm using where SwiftOSC was installed via CocoaPods, commenting out these lines doesn't work.
>
> Is there an easy fix?
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub, or mute the thread.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
jcurtis-cc commented
The lines you provided above force the slash - which doesn't fix the issue when server parsers aren't written to expect it
… On 23 Nov 2018, at 04:09, devinroth ***@***.***> wrote:
It will be safer if you change to the following.
if address.first != "/" {
self.string = "/" + address
}
Haven't tested but it should work. The will not work without the leading "/" so this way you make it optional to add and add it if it doesn't exist.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
jcurtis-cc commented
For context:
How oscP5 servers handle addresspatterns without opening slashes from clients:
How SwiftOSC servers handle addresspatterns without opening slashes from clients:
devinroth commented
I’m following exactly what in the OSC spec.
"An OSC Address Pattern is an OSC-string beginning with the character '/' (forward slash).”
http://opensoundcontrol.org/spec-1_0 <http://opensoundcontrol.org/spec-1_0>
The implementation in oscP5 (processing), ofxOSC (openFrameworks), MaxMSP is invalid according to the spec which is why they show up as invalid. I wouldn’t be surprised if all of those programs use the same open source framework that allows the invalid addresses.
Feel free to change the code to fit your needs but I will have to do some research and give it more consideration before I make it a permanent change. Playing well with others is important despite the spec. Maybe the solution is to accept the values but give a warning. To properly implement it will take me time.
For a quick fix for you just download the source and compile the framework yourself.
… On Nov 22, 2018, at 6:03 PM, Jay Curtis ***@***.***> wrote:
For context:
How oscP5 servers handle addresspatterns without opening slashes from clients:
<https://user-images.githubusercontent.com/25715542/48926201-049a1980-ef20-11e8-90ba-96631ca47e06.png>
How SwiftOSC servers handle addresspatterns without opening slashes from clients:
<https://user-images.githubusercontent.com/25715542/48926231-2c897d00-ef20-11e8-8860-009e99e442b1.png>
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub <#29 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMaIESfJM1K6utKwHk3ManXPaavzkg9eks5ux1d8gaJpZM4YuuTI>.
jcurtis-cc commented
Thanks Devin, I think you are probably right here - they all could be using the same base framework which is ignoring that spec
Requesting you pivot your code around this is probably a bit too preemptive - sorry for that! Mind if I fork it instead?
Btw really enjoyed the generative swift midi stuff!
Cheers :)
J
… On 23 Nov 2018, at 18:02, devinroth ***@***.***> wrote:
I’m following exactly what in the OSC spec.
"An OSC Address Pattern is an OSC-string beginning with the character '/' (forward slash).”
http://opensoundcontrol.org/spec-1_0 <http://opensoundcontrol.org/spec-1_0>
The implementation in oscP5 (processing), ofxOSC (openFrameworks), MaxMSP is invalid according to the spec which is why they show up as invalid. I wouldn’t be surprised if all of those programs use the same open source framework that allows the invalid addresses.
Feel free to change the code to fit your needs but I will have to do some research and give it more consideration before I make it a permanent change. Playing well with others is important despite the spec. Maybe the solution is to accept the values but give a warning. To properly implement it will take me time.
For a quick fix for you just download the source and compile the framework yourself.
> On Nov 22, 2018, at 6:03 PM, Jay Curtis ***@***.***> wrote:
>
> For context:
>
> How oscP5 servers handle addresspatterns without opening slashes from clients:
>
> <https://user-images.githubusercontent.com/25715542/48926201-049a1980-ef20-11e8-90ba-96631ca47e06.png>
> How SwiftOSC servers handle addresspatterns without opening slashes from clients:
>
> <https://user-images.githubusercontent.com/25715542/48926231-2c897d00-ef20-11e8-8860-009e99e442b1.png>
> —
> You are receiving this because you modified the open/close state.
> Reply to this email directly, view it on GitHub <#29 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMaIESfJM1K6utKwHk3ManXPaavzkg9eks5ux1d8gaJpZM4YuuTI>.
>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
devinroth commented
Please fork. And like I said I will consider making a change.
Thanks for bringing this to my attention.
… On Nov 22, 2018, at 11:36 PM, Jay Curtis ***@***.***> wrote:
Thanks Devin, I think you are probably right here - they all could be using the same base framework which is ignoring that spec
Requesting you pivot your code around this is probably a bit too preemptive - sorry for that! Mind if I fork it instead?
Btw really enjoyed the generative swift midi stuff!
Cheers :)
J
> On 23 Nov 2018, at 18:02, devinroth ***@***.***> wrote:
>
> I’m following exactly what in the OSC spec.
>
> "An OSC Address Pattern is an OSC-string beginning with the character '/' (forward slash).”
> http://opensoundcontrol.org/spec-1_0 <http://opensoundcontrol.org/spec-1_0>
>
> The implementation in oscP5 (processing), ofxOSC (openFrameworks), MaxMSP is invalid according to the spec which is why they show up as invalid. I wouldn’t be surprised if all of those programs use the same open source framework that allows the invalid addresses.
>
> Feel free to change the code to fit your needs but I will have to do some research and give it more consideration before I make it a permanent change. Playing well with others is important despite the spec. Maybe the solution is to accept the values but give a warning. To properly implement it will take me time.
>
> For a quick fix for you just download the source and compile the framework yourself.
>
>
>
> > On Nov 22, 2018, at 6:03 PM, Jay Curtis ***@***.***> wrote:
> >
> > For context:
> >
> > How oscP5 servers handle addresspatterns without opening slashes from clients:
> >
> > <https://user-images.githubusercontent.com/25715542/48926201-049a1980-ef20-11e8-90ba-96631ca47e06.png>
> > How SwiftOSC servers handle addresspatterns without opening slashes from clients:
> >
> > <https://user-images.githubusercontent.com/25715542/48926231-2c897d00-ef20-11e8-8860-009e99e442b1.png>
> > —
> > You are receiving this because you modified the open/close state.
> > Reply to this email directly, view it on GitHub <#29 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMaIESfJM1K6utKwHk3ManXPaavzkg9eks5ux1d8gaJpZM4YuuTI>.
> >
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub, or mute the thread.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub <#29 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMaIEZ9z7T1rjVr0YZBUMmFPjRAWwaOMks5ux6WNgaJpZM4YuuTI>.
jcurtis-cc commented
Thanks Devin - after doing some digging around here I found this. Lots of great thoughts about this same issue. I think you are spot on about being built on the same framework (oscpack perhaps)
colinbdclark/osc.js#72
It feels like somewhere a decision was made to support using plain strings and ints as addresspatterns for use with supercollider.
Adhering to the protocol seems like a good idea though!
It's an odd situation because of all the primary popular media frameworks all ignore it. I'll fork it and submit a PR linking this issue when I get time after this project.
… On 23 Nov 2018, at 18:02, devinroth ***@***.***> wrote:
I’m following exactly what in the OSC spec.
"An OSC Address Pattern is an OSC-string beginning with the character '/' (forward slash).”
http://opensoundcontrol.org/spec-1_0 <http://opensoundcontrol.org/spec-1_0>
The implementation in oscP5 (processing), ofxOSC (openFrameworks), MaxMSP is invalid according to the spec which is why they show up as invalid. I wouldn’t be surprised if all of those programs use the same open source framework that allows the invalid addresses.
Feel free to change the code to fit your needs but I will have to do some research and give it more consideration before I make it a permanent change. Playing well with others is important despite the spec. Maybe the solution is to accept the values but give a warning. To properly implement it will take me time.
For a quick fix for you just download the source and compile the framework yourself.
> On Nov 22, 2018, at 6:03 PM, Jay Curtis ***@***.***> wrote:
>
> For context:
>
> How oscP5 servers handle addresspatterns without opening slashes from clients:
>
> <https://user-images.githubusercontent.com/25715542/48926201-049a1980-ef20-11e8-90ba-96631ca47e06.png>
> How SwiftOSC servers handle addresspatterns without opening slashes from clients:
>
> <https://user-images.githubusercontent.com/25715542/48926231-2c897d00-ef20-11e8-8860-009e99e442b1.png>
> —
> You are receiving this because you modified the open/close state.
> Reply to this email directly, view it on GitHub <#29 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMaIESfJM1K6utKwHk3ManXPaavzkg9eks5ux1d8gaJpZM4YuuTI>.
>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
devinroth commented
Thanks. That was a good read. I think I agree with @colinbdclark on this. Best of luck with your app.