I wanted a serialosc solution that worked the same way my MIDI keyboard works when I plug it in and any app already running, detects it, registers it, and is ready to go. Plug and Play Baybee! (That seems to be what serialosc is hinting at.)
That's what this patch does. Using dynamic scripting, it creates and deletes serialosc udp connections on the fly with an appropriate routing protocol to work through just one inlet and outlet in the master patch serialoscAFAC.maxpat(which is what you load into a bpatcher). In short, it allows an app you develop using this, to simply work upon plug/unplug of any number of devices(no more need to use multiple serialosc.maxpat patches to account for multiple devices, just one patch does and detects it all).
To use and especially to modify this thing, you should already be familiar with the original serialosc.maxpat. Of course, you must have serialosc itself installed already. See the attachment to this thread if you need help where I commented the original patch:
Please start by looking at serialoscAFAC-Starter.maxpat
There is a hidden button at the top-left corner of the dusk-colored interface. A comment points directly to it. Click in this area and the bpatcher will reveal itself in patching mode so that as you plug and unplug different devices, you can see how it creates objects and connections on the fly.
Let me know if you have any questions.
**See new SerialOSC_AFAC.zip attachment in my 8/14/2012 post below for latest version of patches and the demo app... will upload to wiki later if it generates interest. Thanks for checking it out.**
good idea, i'm curious to see how you like the usability of auto-selecting.
and yes, i hope we see some action from FTDI soon on this kernel panic matter.
Thanks raja... I look forward to digging through the patch!!!
please send your kernel panic logs to my email address (you have it). could you also let me know what system you're running (i.e. macbook, mac pro), what OS version, whether it's plugged into mains or not (the FTDI people ask me this every time), and whether you're using a USB hub too.
really appreciate it. ftdi grrrrrrrrr.
macbook? plugged into mains or on battery? (ftdi wants to know)
it looks like none of those issues are FTDI-related, they all look like sloppy coding in the max/msp bonjour externals. i'll try and look into it tomorrow...it looks like a threading issue though. seems that one thread is free()ing something and another thread is trying to use that pointer afterwards. this is the error i think we're seeing in the KERN_INVALID_ADDRESS crashes.
the other .crash files look like a NULL pointer dereference...looks like DNSServiceRefDeallocate is getting passed a NULL and then it internally casts it to a struct and indexes into it (which is why the addresses are so low). i think? might be, can't say for sure.
the .hang seems to be unrelated...though, huh, I didn't realize max/msp was a juce app!
you should check and make sure you're using the objects correctly, could just be a lack of error checking. on the other hand, these externals may have just be coded sloppily, i can't say for sure.
still, no FTDI bugs here.
I must be doing something wrong. I tried using this in polygome as a test but i don't get any response. max window says something like-
binding to port 17812
binding to port 18164
zeroconf.service: Service published: 18164
I renamed serialoscFAC.maxpat to serialosc.maxpat and replaced the one in polygome's folder (along with the sosc_portloader file). what else do i need to do?
and btw, i got some crashes with more than one instance open in max (serialoscAFAC-Starter and serialoscAFAC) it looks like they're competing for the connection, then max crashes.
oh, sorry, this is for devs to incorporate into their app, so polygome would have to be edited to use this.
I assume the zeroconf...mxo files are redundant or no?
yes, redundant. my bad, i include them in everything i hand out just to be on the safe side. if you already have em you can delete the ones included here.
hmmm.... I only have one device, but i like the idea of monome "plug n' play". never thought i'd hear the two in the same sentence. Pages makes the monome pretty much plug n play, as long as you're using only monomeserial apps and save your config. serialosc apps though require you to hit connect, so you have to go through and connect each one individually. thats where serialosc becomes a big pain in the ass for me, so i tend to use monomeserial versions with Pages if i have a choice. i like where you're going with this though, ditching the 'connect' button and making things more convenient.
if you have only one device and need automatic plug n' play, i've attached a simple edit to the regular serialosc.maxpat here, it connects the first thing it finds in the umenu after 2 seconds... should replace other serialosc.maxpat just fine.
Trying to get my head around the 'route 0 1' within the host app.
in obo where I used to do this:
now I would do:
route 0 1
Then do I duplicate all the button press stuff and send the second outlet of route object to it?
that totally makes sense now.
I can see now why it's so hard to come up with auto connecting solutions for multiple devices that are an open grid of varying size.
hey, thx. that works great.
i'll add one thing though, since we're on the topic of editing the serialosc bpatcher. Static OSC ports that can be saved on a per patch basis would make things a lot easier in some cases. but would you still need to hit 'connect' to send/receive data if your monome set to the correct osc ports and prefix? (connecting to max apps via Pages)
just tried your attachment, then when i was editing the arguments in polygome, I noticed stretta already had- 9001 /gome, so it would always bind to port 9001. it turns out the original bpatcher could already do that.
the thing is, every external app page in Pages is its own virtual monome in serialosc. So when u do the auto-connect, it changes the ports of whatever page its connecting to (the top or any newly created page). However when u use monomeserial apps with pages, they're constantly broadcasting on static ports so the connection is instant. Is there anyway to just keep the connection open and ports static like monomeserial apps did?
Ok, i think i understand... not knowing a great deal about Pages, though...
try this attachment. this may be easiest to do if we do away with zeroconf max objects altogether and just go with the static port information in the serialosc .conf file(which is different for every computer/monome/setup)...
here's what my .conf file says:
port = 14824
osc_prefix = "/example"
host = "127.0.0.1"
port = 29755
rotation = 0
So you'll need to find your .conf file(on OSX, it's in the Library/Preferences/org.monome.serialosc folder, and the Library folder may be in your root directory or your home/user directory depending on the version of OSX, but on Windows it's a bit more complicated to find, so do a search on these forums if you don't already know...)
The attachment here, loaded into a bpatcher, takes 3 arguments:
1) 'application' port
2) 'server' port
3) app prefix
(for example, from the info. specific to my monome and computer in the above mentioned .conf file example, and with an app prefix of '/crazy', the argument field for the bpatcher loading this patch up would be: "29755 14824 /crazy")
if this isn't what you're looking for, then the prob might be at the zeroconf level which is above my head at the moment.... hope this works for ya.
it may still be beneficial for me and others to see a boiiing example. As I move forward in obo (which has tons of subpatchers) its unclear to me whether I just need to duplicate the entire patch or just certain components.
Ok, as promised, here's a demo app.
a bit like boingg, except just a 'notes' page and a 'sequence' page
To switch between pages, you hit the top 2 buttons of your monome as shown in x's here, no matter what size monome:
nice, somewhat commented demo... but reckon the app itself may need some explanation in terms of tweaking synthesis parameters
If enough people are interested, i'll start putting a page up on the wiki, otherwise, i'll just leave it here, haphazardly organized around this thread :D
awesome !! I will be getting all up in this patch tomorrow in the a.m.
Cool bananas! I forgot about this with all the excitement of the MCRP going on, but am home tonight and just downloaded and started playing with this app. Its excellent raja, I especially like the variety of control parameters you have provided for shaping the sound. It connected to my GS 128 straight away and within seconds I was playing around with it and bouncing sounds! Nice one, thanks for sharing this!
osx molehill pussy!
I honestly think this one is deserving a place in the apps documentation Raja!
It has a surprising degree of depth to it. I'm a simple soul and get captivated by flashing bouncing/moving lights very easily but the number of options to shape your sound remind me of a good analogue subtractive synth **//and//** the permutations of sequencing that you've provided with the notes selection (polyphonic chords etc) combined with the classic boing-type action seem pretty damn limitless to me! (hope that all makes sense, it's early and I am yet to have a caffeine infusion)
LOL, love your thinking out loud, even though I admit to not understanding it all. I really must start making time to look at how all these things patch together. I have m4l but haven't had time to explore it yet...
FYI the app automatically recognised & connected to my GS64 as well as the 128 (and if I had enough USB ports I am sure it would recognise my walnut 64 as well)
I have a wish list for this app (cheeky beggar that I am) - midi out with channel selection for each device and individual oscillators for each device would be sweet!
Thanks again for giving me another fun app to play with Raja!
Dug up this thread because I was wondering how to make my set-up autoconnect. Not much the wiser - Raja - beginner's guide? I can do basic Max coding; I have a few patches which I'd like to load and automatically connect to Pages external pages...
Cheers k. I'll have a dig around and if I can't find anything I might start a new thread.
Also look at the serialosc_development patch for working examples of auto focus/ auto connect.http://monome.org/docs/tech:dev:tools
what @emergencyofstate said. i believe this functionality is already implemented / able to be implemented (depending on your patch) already.have a look at mlrv's handling for an example of how you might store the monome deviceid and auto-recall upon loading a preset into your patch.
I've never looked at that page before. Fascinating! Digging into it now...
@declutter -- it's great. That patch has been the starting line of everything I've "built" to this point.
Ok, so the auto connect thing is actually very easy, following the instructions given. Two small learnings for me which might help others:1) I had to make sure I was using a more up-to-date serialosc.maxpat (am I the only one who has dozens of serialosc.maxpats around their hard drive and is never totally sure which one each patch is using?)2) within m4l, a delay of 100ms after the patch loads before sending the message with the deviceid ensured that it worked.
yes max4live is a little frustrating with initialisation timings (particular when using pattr)secondly - you can use my technique of doing a search for serialosc.maxpat - deleting them all - then downloading the newest version from here and putting it in your max folder.then everything uses the same one and it's easy to universally update!