serialosc.maxpat >> alternate zeroconf (bonjour) version

  • i've created an alternative to the serialosc.maxpat that communicates directly to serialosc via UDP. this uses the zeroconf setup to allow patches to function as virtual devices (as required by pages for example).

    please note: this is not un upgrade from the other patch, but rather an option to allow pages users to use the same setup as other users.

    the functionality is identical to the new version except the following:
    - the 3rd outlet sends the full zeroconf name as a symbol (eg. "monome 128 (m128004)")
    - the internal pattr object stores and recalls based upon the abovementioned full-name

    apart from this they are fully compatible.

    ***EDIT***

    Please be aware you will need to install the "zeroconf" max externals.

    see: http://monome.org/docs/app:serialosc:zeroconf

    At present these will only function in 32bit mode — If you're using Max6.1 make certain you're not using 64-bit (right-click & get info on the Max application)

  • thanks galapagoose! i updated the pages wiki to point to this post.

  • @galapagoose
    Do you think ti might be possible to merge the two? perhaps test for bonjour support and fallback to osc based discovery if support is not offered?

  • i don't think bonjour should be the primary mechanism. the osc based system is faster in terms of startup speed and propagation. if the can be merged it'd make sense for there to be a saved preference for one or the other perhaps.

  • it is quite frustrating trying to make the two different approaches co-exist — they respond to entirely different messages from serialosc which makes the code quite different between the two.

    sure, it would be possible to add a switched mechanism inside, but thinking of use cases i can't really see the point. here's my perception of real-world use:

    for a new user:
    - installs the UDP version which always recognises and loads your device correctly
    - has less chance of causing firewall issues on windows, and more reliably recalls devices

    when somebody decides they want to try pages (currently the only app that needs zeroconf??), they can then experiment with the zeroconf patch.

    at least this way we make sure people get up and running to start with, before they try messing with too many things under the hood.

  • after experience programming for both methods i agree with galapagoose and tehn that bonjour should not be the primary mechanism. the udp method is quicker, simpler and should be easier for users of all operating systems.

    however, i feel this has left us in a grey area, or at least new territory, regarding intermediary routing, spanning or app switching applications.

    i'm thinking the inclusion of a system to do this within serialosc would be a bit out of it's scope. for instance a way of creating virtual devices which are added to the serialosc device list and can have their serialosc settings changed like normal devices, all over udp. too much?

    otherwise bonjour seems like the best option as it 'should' be well supported on all OS's and seems to be used increasingly. but i don't think there's yet a protocol for how to create a virtual device over bonjour. for instance what messages it should receive, react too and pass on to the real device. what name it should identify or advertise itself as to be seen by all monome bonjour enabled apps.

    although i really like the elegant simplicity of the new serialosc.maxpat and connection mechanism, i'm still not sure why random port allocation is used. building the monome home patch and being able to quickly view and edit each devices ports then match them to an applications ports made me miss that method. i could be mistaken but it seems most monome users are familiar with setup routines like checking controllers are talking on the same midi channel, or routing audio around different locations. are there other advantages to using random port generation, other than simplicity for basic, maybe most, setups? would it be useful to allow users to see and edit the device send port in the serialosc.maxpat? or should this be kept for other apps designed for this purpose, i.e monome home?

    what are the reasons for fading out use of a device prefix? could we expect it to eventually be removed in future devices and firmware updates. it does seem quite redundant now and i prefer using individual ports for each device instead. but just for information are there any disadvantages to using the same ports with different prefixes for all devices. could there be problems if too many messages are sent to the same port at once? or is it mainly to avoid sys message confusion as these don't get prefixed?

    finally, for routing/spanning/switching do people think it would be best to make one app which deals with creation of all virtual devices, deals with all of the physical devices, and allows for all routing, spanning and switching between them? or would it be best to think of a more modular system where an extra bit of code could exist in each individual monome app to allow routing/spanning/switching?

  • the new serialosc.maxpat is specifically designed to be simple and yet powerful. it implements the original intent of what serialosc was planned to do, and the random port number is a consequence of that. the whole system is designed such that you can open any number of patches (even duplicates) and they'll elegantly, and automatically handle the devices.

    monome home seems an interesting tool to see all of your connected devices at once, though with the random setup, the necessity of knowing which port your device / patch is on seems almost unnecessary? i'm curious what benefit you're getting out of using it — perhaps if you have a lot of devices open?

    i would tend to assume that most users have only one device, so i think the standard arrangement should be focussed on that setup — perhaps 1 grid and 1 arc at max. beyond that, we should make sure things work as add-ons, rather than requirements. it's very important that we don't make the setup for a new user any more difficult than it is (the amount of first-time user support on these forums is proof enough of that).

    regarding prefixes, you are correct in stating they have become redundant since the rollout of the port-per-device / port-per-patch serialosc. this is not so much a 'reason' as it is an observation.

    there was discussion of having a mode in serialosc that could run without a prefix, but it was decided it would be easier to simply make a default prefix for new apps (hence "/monome"). as it stands, prefixes are only relevant within the port (ie. per instance of serialosc.maxpat), so you could theoretically have an app that routes presses, and selects led streams based on /sys/prefix messages, but it would be far more elegant to include that switching mechanism inside your app.

    re: ROUTING / SWITCHING / PANNING
    personally i think it's important to make this functionality work via an external patch, rather than included extra code in already distributed patches (it takes a long time to comb through the wiki!).

    ROUTING seems easily accomodated by this method. have an app (like the old quadrants) which connects to the serialosc server, then spawns a number of sub-devices hosted back to serialosc. obviously requires the zeroconf version, but is simple enough.

    SPANNING could be implemented in the same way as above, though perhaps there is a better solution (this used to be very easy monomeserial simply setting an offset for a second device)? for plane, stretta simply included 2 copies of the serialosc.maxpat to span across the 512 (as 2, 256s).

    SWITCHING is currently able to be handled in a brute force method (ie sending a bang to the 2nd inlet of serialosc.maxpat), though this doesn't allow switching from the box itself. is there an accepted way of how people wish to use this functionality (eg. lose a row of their monome, dedicated to switching? dedicate a 'shift' button?)

    **

    i'm going to have a good look at how pages actually works (never downloaded it before!) and see if that helps me sort out the positives / negatives...

  • @phortran
    i uploaded the zeroconf-serialosc.maxpat to the wiki and changed the pages wiki to point to it directly.

  • thanks for indulging me.

    will proceed with an external/all-in-one max based routing/spanning/switching app now. prefixes set to /monome and ports set to randomise!

    monome home was just an experiment and exercise really, trying to get more familiar with serialosc, and the beginnings of some ideas for the route/span/switch app. i'm still using a version of serialosc.maxpat i programmed with static but editable ports, so has been of use to me working with that. as you say not so useful with randomised ports, except to change rotation, intensity and such. just easier for me to think about a routing app in terms of how it used to work, setting ports etc, but using randomised ports and bonjour will be much more elegant.

  • @galapagoose
    thanks for updating the pages wiki!

    maybe editing the griddle wiki with the same instructions as to the pages wiki would be a good idea. pointing directly to zeroconf-serialosc.maxpt plus all the other nicely detailed instructions...

    i have been doing some testing and it seems like griddle also needs the zeroconf files (placed inside max-externals folder) and zeroconf-serialosc.maxpat (placed inside patches folder) in order to be recognized by the new apps, for example mlrV2.3.

    cheers

  • that sounds about right. feel free to edit it yourself (your forum login works there too)!

  • cool, did not know i was able to do it! thanks!

  • thanks for updating that galapagoose! just want to say i love this idea of "BYO serialosc patch"