monome

SerialOSC With Other Languages?

general
  • MCDELTATMCDELTAT

    Hey there guys,

    I was wondering what are the plans to get serialOSC into other languages. Since it's currently limited by the maxpatch to connect, how do we plan to implement this? Personally I think for text-based languages it would be great to simplify this down to just a header file that can be included, used in languages like C/C++ and Chuck (which uses C/C++ headers doesn't it?)

    What about for PureData?

    I think that this would help get apps (and people) moved over to the new standard.

    I'd be more than abliged to take on some of this work, assuming will or someone can explain how serialOSC handles everything....

  • ioflowioflow

    You do know that serialosc is already written in C, right? It's not written in Max/MSP at all. There are other apps that use serialosc with no need for Max, such as rove and griddle.

    Also, for working with monomes, there's a separate project, libmonome, to help get you started. There are even Python bindings available, though they're currently broken; need a bit of work for the latest protocol.

    Anyway, for learning how serialosc works, hit up the wiki and start reading protocol and tech docs.

  • MCDELTATMCDELTAT

    Well I know that it's written in C, I've checked out the source, but I'm speaking more from a GUI perspective here, with a few other ideas.

    If you look at the old list of apps, the three most popular languages are MaxMSP, PureData, and Chuck. The others are kinda sparse like a couple written in Ruby, Python, or C.

    So it's more of a question of how do we get serialOSC into chuck? Puredata? Processing? I've been wanting to practice these languages more, but I find it tedious to turn off serialOSC each time I need to go back and use monomeserial.

    I think we can fairly easily build a header file for these languages that can just be inserted without much change to the source that we have now.

    EDIT: We can use to HTML in our text posts now? I see you created dynamic links up there.

  • BoxieBrownBoxieBrown

    Speaking of Pure Data. I made an update to PUMA, which includes a SerialOSC version of the puma.connect abstraction.

    http://post.monome.org/comments.php?DiscussionID=8681&page=1#Item_17

    I never heard back from anyone that tried it, so it seems to work on my end, but it's possible there are some issues.

  • MCDELTATMCDELTAT

    Sweet! Will look at those today. So perhaps we only need a chuck header file and a processing header now.

  • tehntehn

    it works exactly like normal OSC, but requires zeroconf. we need to promote efforts for zeroconf implementations in other languages...

  • BoxieBrownBoxieBrown

    I'm not sure what's involved with extending the Chuck language, but it looks like this is already built into SuperCollider if I'm not mistaken.

    I'll also put this out there, Murray's simplebonjour external for Pd still needs a windows build if anyone wants to try that.

  • trisstriss

    There's no method for finding for device discovery built in to SC yet. It registers itself as a client but can't browse for others.

    I've got something working on Linux that involves shelling out to avahi-browse and am attempting to get it up and running on OS X using dns-sd. It's dirty but it works and can be hidden entirely from the user. It doesn't require people install extensions for stuff tho which is nice.

    fingers crossed I'll have something ready tonight if work doesn't wipe me out today.

  • BoxieBrownBoxieBrown

    Ahh ok, that makes sense.

  • visininvisinin

    i'd like to build zeroconf bindings for supercollider, i really would...unfortunately, building that sort of language extension was a very complicated process, and i gave up not long after starting. the docs are (were?) very thin.

  • MCDELTATMCDELTAT

    @visinin
    I feel you. I was looking at building some for Chuck and can't seem to find much. They have a developer page of topics with no links. All I know is the extensions (.chk) can be built from C/C++ so it shouldn't be hard.

  • ioflowioflow

    chuck is useless to me, as long as it won't compile or run on 64-bit processors. and no, trying to do it in a 32-bit chroot isn't a viable option. but there's been no progress made in years on making the code 64-bit-safe. chuck as a project seems to be stagnating, even dying. i don't plan on using it for anything. it's a shame, too, because some of the simplest, nifty monome apps are written in chuck.

  • BoxieBrownBoxieBrown

    @MCDELTAT
    I was also looking into what is necessary for Chuck development, but it was fairly difficult to find anything. There is this tutorial on how to create you own UGen, which might help someone figure it out.

    http://wiki.cs.princeton.edu/index.php/ChucK/Dev/UGen_Tutorial

    Though, I agree with nightmorph, chuck seems to be in this abyss where there aren't many (or any) people actively working on it. I'm torn on whether it's worth trying to develop for it. On one hand, if nobody tries to update anything it just contributes to the problem, but on the other, you could be working on something nobody will use.

  • 9595

    ioflow!

    new chuck

    64 bit

    download > http://chuck.cs.princeton.edu/release/
    whats new > http://chuck.cs.princeton.edu/release/VERSIONS

    also in this update - input and output in stereereo