Osc

[jim]

Several folks have mentioned that they would like to see OSC in Numerology. I'm making this post as a call for information on:

• What existing hardware and software do you have that supports OSC?
• How do you use OSC in your setup already?
• What kind of OSC support would you like to see in Numerology?

Cheers,
Jim

[amsonx]

• What existing hardware and software do you have that supports OSC?


Cheers,
Jim

I' use Arduino that can be deal with OSC
as software Isadora (http://www.troikatronix.com) and VDMX (http://www.vidvox.net) and Quartz Composer and Plogue Bidule.

[steff3]

hello,

software already: Max/MSP-Jitter, Bidule

what kind of modules:
I would like to have a tag sequencer - like sequencer that sends tags/word commands on the time slot - like the matrix sequencer, only that it does not trigger note messages but text messages

best

[wwinfrey]

Hardware employing OSC: JazzMutant Lemur, Monome64
Software employing OSC: Max/MSP, Reaktor, Circle, Plogue Bidule

What I would like to see: bi-directional feedback between controller and Num, i.e. I set up a MonoNote module in Num. MonoNote has 10 parameters. I'd like to be able to control those parameter changes from the Lemur, as well as have the Lemur's interface change when any of those parameters are adjusted by the mouse, or another process in Num.

Perhaps a really-flexible OSC module, that can say, have it's messages configured with an XML file while the routing is handled via the GUI, would be a decent way to go.

[jim]

Any chance you could post some example messages or setup info from your Lemur setup?

One option I'm considering is using a fixed 'control message' for all parameters based on the stack/module/param name, for example: "/stack1/mononote1/octave", with the option to 'learn' an additional message for controllers that have already been programmed. However, having not investigated common OSC usage, I may be off-track a bit...

Jim

[jim]

hello,

software already: Max/MSP-Jitter, Bidule

what kind of modules:
I would like to have a tag sequencer - like sequencer that sends tags/word commands on the time slot - like the matrix sequencer, only that it does not trigger note messages but text messages

best

Would you just need to generate one message with different values, or completely different messages per step?

Thanks,
Jim

[wwinfrey]

Any chance you could post some example messages or setup info from your Lemur setup?

As soon as a I get a spare 30-45 minutes to go through a configuration and put together an explanation, I'll post it up here. :-)

[steff3]

Would you just need to generate one message with different values, or completely different messages per step?

Thanks,
Jim

Bot sure if we are talking about the same thing.

my idea is something like having a tag trigger like the Matrix seq - so in the column you write the note name or sound for the matrix seq you can write the tag or command (e.g. sweepstart or fadeout - see below). then you have those cells/steps in the row where you can a specify at what time to send that command. (like in the matrix seq this can be the normal rectangle - the tag is outlined at the start of the row)
I mean it would be another idea to use the tag inside the cells, but I think it might get hard to read them - so for e.g. sweepstart and sweepbreak or whatever it might be easier to use two rows, one of each.
Maybe I should make a moke-up screenshot how I think about that.

In the different rows you can have different commands (or better, different messages, where you can go to a completely different location in the Max-patch - /soundgen/voice1/sweepstart and /fx/delay/fadeout or something like that.)

Hope that is a bit clearer now :)

best

[jim]

How about an expandable list of messages that can be triggered by Note messages (or other events). The nice thing about note messages is that you
get two high-resolution values (note number and velocity) that you could insert as args into the OSC messages. (remember, Numerology's note messages have much higher resolution than MIDI...).

Ltr,
Jim

[steff3]

>>
How about an expandable list of messages
>>

Well, just to make sure I understand that - you mean you assign messages to pitch so that pitch A triggers one command/message and pitch B another? And therefore you can also use the velocity as another value?

It depends how readable it is. I think this is a very important point - having already the whole Max/MSP-cluttering, x message-channels and so on, I think it is important that readability is better than if I would do the same in Max (which can be basically down, but ...)
Besides that, if you get the message command on pitch and another value on velocity - that is about the same as you get in the Matrix sequencer - as there is also a velocity. (ok, there you might have the problem that all commands in one step only have one velocity like with poly note).

I think - like with 'MIDI/CV' seq (well, they output to MIDI) it would be great if there were also different approaches to OSC-related sequencers. For me one concern would be to have a readable measure-based approach.
I like more the idea of triggering behaviour/gestures etc. - so to send a single value with that command might not always help at all. Instead I might use a tag to trigger a pre-recorded or designed 'behavioural sequence' so to say. (e.g. something in ftm or so)

Another concern is - but very theoretical at this point as I think one has to see that in an actual project - if and how Numerology could be integrated into a subnetwork that does debug messaging. Lately I really start to set up such networks to print out the messages to see if there is an error in the scheduling etc. So one could pin the debugging at the border between Max and Num but that might not catch all problems. Well, I think something like that has to be seen in an actual project - but maybe some others also have their approaches and want to share ....

Just my thoughts

thanks for listening.

best

[sonomute]

Hello again.

I also think if you will add OSC support to Numerology it will move it to the next level and more people working in areas of computer music/sound art will be interested in it.

I`m using for the moment TouchOSC software for Iphone, which is kind os multi touch control surface(client) sending osc messages to computer(host).

Because OpendSoundControl by it`s nature network protocol Numerology must be able to work as network server/host. Basic parameters defining host must be- host name (i think it will work even without name, but in case somebody using couple of different progs it can be handy),IP adress, port. Protocol means something universal, kinda language, it has structure, and since host understand this language and can reroute messages it gets from client to different parameters of it`s own it is no matter what other software in use.

More about protocol here:
http://opensoundcontrol.org/

also you can find there a lot of different libraries for most of programming languages to implement OSC in your projects.

I will be glad to assist you in searching information and testing if you need such a help. I`m not a programmer, even if i have some basic knolege about Python as well as Max/Msp, PureData, Supercollider and some others...

We can build example patches for max and PD for people who want to start to use numerology with their soft.

Also, i`m sure that people from Monome community will be happy to use their beautiful controllers (OSC based of course) with numerology, it is very similar paradigm in a way...

http://monome.org

[jim]

>>
How about an expandable list of messages
>>

Well, just to make sure I understand that - you mean you assign messages to pitch so that pitch A triggers one command/message and pitch B another? And therefore you can also use the velocity as another value?


Something like that, each entry in the table would have (at least):

• A minimum note number
• A maximum note number
• An OSC message (OSC address, type tag, args)

Anytime the module gets a note on message, it looks up any OSC messages that respond to that note and sends them. I would implement an expression so you could insert velocity values into the OSC message. For example, in "/some/device/name ,f <V>" the "<V>" would be replaced with the velocity value. Of course, pitch values could be used also, making it easy to generate OSC 'note' commands.

Also, I could easily extend Numerology Note messages to include "extra values", such as CC values from the Mono/Poly note, so then you could generate OSC messages with multiple values. A Note message would then look like this:

[Note On, <note number>, <velocity>, <cc1>, <cc2>, <cc3>]

The appeal to me of using Notes to trigger OSC messages is that it allows a great deal of reusability of what we have already: a lot of ways to generate and process notes.

Now, this does not preclude the existence of a CV/Gate based module to generate OSC, I think that has its place also, but the note based approach makes it much easier to pack lots of messages into one module, trigger multiples of them with single events, etc.

It depends how readable it is. I think this is a very important point - having already the whole Max/MSP-cluttering, x message-channels and so on, I think it is important that readability is better than if I would do the same in Max (which can be basically down, but ...)
Besides that, if you get the message command on pitch and another value on velocity - that is about the same as you get in the Matrix sequencer - as there is also a velocity. (ok, there you might have the problem that all commands in one step only have one velocity like with poly note).


Of course, readability (and usability) is very important. I don't know exactly what this module would look like but it would just be some sort of table, with columns for the note range, and the OSC message itself.

I think - like with 'MIDI/CV' seq (well, they output to MIDI) it would be great if there were also different approaches to OSC-related sequencers. For me one concern would be to have a readable measure-based approach.
I like more the idea of triggering behaviour/gestures etc. - so to send a single value with that command might not always help at all. Instead I might use a tag to trigger a pre-recorded or designed 'behavioural sequence' so to say. (e.g. something in ftm or so)


ftm??

I much prefer to keep OSC generation outside of a sequencing module -- Not only are sequencing modules a lot of work to build and maintain (despite lots of reusable code), embedding OSC generation inside a module would subvert the benefits that come with modularity. I did implement some 'embedded' behavior with CC messages in the NoteSequencers, but only as a convenience, and only well after the standalone CC Gen module had been created. I expect OSC's presence in Numerology will evolve in a similar manner: first a small set of key modules to cover a large range of applications, then later augmented by some built-in behaviors, once a set of standard usage patterns have evolved.

Another concern is - but very theoretical at this point as I think one has to see that in an actual project - if and how Numerology could be integrated into a subnetwork that does debug messaging. Lately I really start to set up such networks to print out the messages to see if there is an error in the scheduling etc. So one could pin the debugging at the border between Max and Num but that might not catch all problems. Well, I think something like that has to be seen in an actual project - but maybe some others also have their approaches and want to share ....


Well, that just argues for a log. Numerology already has one for me to debug with, but here I'm thinking more of a user log -- a window that you can open and see events like MIDI, OSC, Transport start/stop etc.

Cheers,
Jim

[steff3]

>> ftm??

faster than music :)

http://ftm.ircam.fr/index.php/Main_Page

generally speaking it is a Max/Pd etc. extension to deal with matrices, tables etc. You can make, manage and use multidimensional sets of data - like gestures. motion paths etc. it is a bit like the Max 'coll'-object - but more powerful .....


What you describe there is pretty much a Look Up Table - if I am not totally mistaken. ('it looks up any OSC messages that respond to that note and sends them') So, it seems it is what I did until now with MIDI - just with higher resolution and now the LUT is within Num and no longer within Max.
the higher resolution is of course beneficial.



>>I much prefer to keep OSC generation outside of a sequencing module --

Of course open modules would be great - you have one module for CV/MIDI or OSC - you go for that with maybe an settings in the extended settings options or with an extra module. And of course modularity within this palettes is also very diserable.

But then OSC has dimensions that MIDI/CV do not have - like text string commands, tags etc. And those help readability. I think they are not the 'one and only' thing, but it would be really great to support them this way.
And Max/MSP-Jitter and Pd etc. do have modalities that are beyond MIDI and CV - visuals, matrices, etc. (However the thing they fall short is the support for a great readable meter based timeline)

I made a mockup - is it possible to paste it here?

thanks

[jim]

>> ftm??
I made a mockup - is it possible to paste it here?
thanks

Yes. I just bumped up uploadable image sizes to 1000x1000, 1MB total file size.

Jim

[sonomute]

I`m really sorry to interrupt, guys, it looks like you have very interesting conversation here:) but if you allow me to say...

OSC is a protocol, MIDI is a protocol.

There is no need to make ANY special modules for OSC, it`s just sounds strange...it is the same thing as to do "special modules for MIDI", see what i mean? Most of modules in it "special for MIDI" )) Just add support for OSC to your program, it is so great and will become even greater! Add access to all parameters of every module in every rack, give them names, for example Stack1/MonoNote1/Gate/1 0.46 and so on, let the software send all the data to specific port and allow to make changes in this data from external sources...no need in super complicated modules in this case, it is very easy to manipulate OSC data in max/msp for example;)

My point is- if you will build special module for OSC it will not be full support of OpenSoundControl, more like "limited support of OpenSoundControl"...what?why limited??

Just take a look at first part of Wwinfrey post, that`s what we really need here...only still no need for "OSC" module.

I hope i`m not insulting anybody...Just trying to clear things...

I`m MA student of "sound in new media" program of Helsinki university of art and design, it does not mean that i`m smarter than somebody else, just studying software design prototyping in specific area of music, interactive and performative art.

And it will be really cool to hear some answer to my post in "silly questions" (oh, sorry-General questions;). Presets and timeline not functional only in demo mode or it`s bug?

Thank you! This is wonderful piece of music software, i will buy it right after it will leave beta stage(hopefully with OSC implemented;)))

[steff3]

Ok,

>> Yes. I just bumped up uploadable image sizes to 1000x1000, 1MB total file size.>>

how? the image button in the message editor wants a link - no upload ...


>>sonomute:
OSC is a protocol, MIDI is a protocol.

There is no need to make ANY special modules for OSC, it`s just sounds strange...it is the same thing as to do "special modules for MIDI", see what i mean? Most of modules in it "special for MIDI" ))
>>

Interesting, I partly disagree. And no, I do not see what you mean .... You are right that OSC, MIDI - and also CV if you like - are somehow protocols. As Jim once pointed out - Num does not generated MIDI but 'CV' and translates that. And of course - there are special modules for MIDI - lots of them - the CV 2 MIDI modules or MIDI 2 CV (Note Gen, CC Gen, MIDI To CV - if that is not exactly special purpose modules to translate between two protocols and support features of each protocol?). There is a whole punch of extra modules for MIDI and some modules (e.g. in the NoteSeqs) have those special functionality built into them.
And you can use program change messages, because it is part of the MIDI protocol and implemented in different ways into Num. And you can use MIDI clock, because it is part of the protocol and is implemented.

So what speaks against adding support for things that are part of the OSC protocol? hmmm .....



Anyways - if we look at the matrix sequencer - you have the column with the note numbers and note names and there is a switch in the extended settings to switch to custom names. This would make it easy to look into the row and everytime a step is active - instead of sending the MIDI note number or pitch CV - have the possibility to take that custom name and send it via OSC. Also the Mute button if the MatrixSeq would be hand for conditional relations. (though readability might be a concern in the Matrix interface).

This was generally the idea behind my mockup. I made the custom name field wider so that you can enter a longer name/tag/command (without getting the chopped off) in there which gets triggered each time a step is set.
Now, there is the question how to add the full message - and I think it would be logical to add an OSC input/output and some OSCprepend and OSCroute modules (sorry, it is pretty much how those are called in Max/MSP).
But maybe it it would be interesting to also be able to compose a longer message in the extended settings of the seq. Or have multiple OSC tag outputs on the back and use other OSC message modules.

Thanks for considering ....

best

[jim]

I`m really sorry to interrupt, guys, it looks like you have very interesting conversation here:) but if you allow me to say...

OSC is a protocol, MIDI is a protocol.

There is no need to make ANY special modules for OSC, it`s just sounds strange...it is the same thing as to do "special modules for MIDI", see what i mean? Most of modules in it "special for MIDI" )) Just add support for OSC to your program, it is so great and will become even greater! Add access to all parameters of every module in every rack, give them names, for example Stack1/MonoNote1/Gate/1 0.46 and so on, let the software send all the data to specific port and allow to make changes in this data from external sources...no need in super complicated modules in this case, it is very easy to manipulate OSC data in max/msp for example;)


I'll definitely be doing something like that -- responding (and optionally sending) a fixed set of messages for all 'remote-able' parameters, but there are definitely cases where having a separate module makes more sense.

For instance:

- You may want to generate OSC 'controller' messages to send to a device (software or hardware), derived from a CV signal in Numerology -- which could be any combination of sequencer CV's or LFO's, envelopes, etc. Having the OSC equivalent of the CC Gen module is the most suitable choice here.

- Or, you may have an OSC device where you have some number of messages that you want to be able to trigger on an "as necessary" basis. If it is just one or two messages, then a "trigger this OSC message when I get a gate" module would be sufficient, but for larger groups of messages, using Notes seems like an ideal technique, as it re-uses an event mechanism that many modules in Numerology already support.

- Or, you may have an OSC device that sends messages, and you want Numerology to be able to detect them and extract useful information. For that case, you would want an OSC equivalent of the MIDIToCv module.

My point is- if you will build special module for OSC it will not be full support of OpenSoundControl, more like "limited support of OpenSoundControl"...what?why limited??

Just take a look at first part of Wwinfrey post, that`s what we really need here...only still no need for "OSC" module.

I hope i`m not insulting anybody...Just trying to clear things...


No problemo -- better to get the detailed feedback on this feature now rather than later... (also see comment below)

I`m MA student of "sound in new media" program of Helsinki university of art and design, it does not mean that i`m smarter than somebody else, just studying software design prototyping in specific area of music, interactive and performative art.

And it will be really cool to hear some answer to my post in "silly questions" (oh, sorry-General questions;). Presets and timeline not functional only in demo mode or it`s bug?

I just responded, see my post there...

Thank you! This is wonderful piece of music software, i will buy it right after it will leave beta stage(hopefully with OSC implemented;)))

Cool -- Also, I'd like to mention that I'm very happy with the feedback I'm getting on this thread. Although the OSC spec is a pretty easy read, since I don't have much experience actually using OSC, I am depending somewhat on those of you that have more experience with it to point me in the right direction.

Which, btw, does anyone know of any conventions in the OSC world for sending notes, or is it always ad-hoc?

Cheers,
Jim

[jim]

Ok,

>> Yes. I just bumped up uploadable image sizes to 1000x1000, 1MB total file size.>>

how? the image button in the message editor wants a link - no upload ...


Weird, I'll look into it....


Now, there is the question how to add the full message - and I think it would be logical to add an OSC input/output and some OSCprepend and OSCroute modules (sorry, it is pretty much how those are called in Max/MSP).
But maybe it it would be interesting to also be able to compose a longer message in the extended settings of the seq. Or have multiple OSC tag outputs on the back and use other OSC message modules.


Can you give me a specific use case where you need to modify the OSC address string? I can see that it might be necessary, but concrete examples will help me out a lot, in terms of coming up with a solution appropriate to Numerology...

Best,
Jim

[steff3]

hello,

>>
Can you give me a specific use case where you need to modify the OSC address string? I can see that it might be necessary, but concrete examples will help me out a lot, in terms of coming up with a solution appropriate to Numerology...
>>

Well, the suggestion for OSCroute and OSCprepend where more motivated by the idea to to move message routing (which prepend is) out of the sequencer module into an extra module - especially when you might use one seq for generating messages for different receivers.

To be honest, I do not know if dynamic routings inside Num are useful. I could come up with examples - e.g. I use a stack in Num to generate a pattern which is triggering different events in Max/MSP-Jitter (sounds, visuals, maybe light control, etc.) and according to some conditions you keep that pattern but change what is triggered or generated by it (and therefore addressing other modules within the Maxpatch - but if it is really the right thing to change the address in Num or if it would be better changed within Max/MSP? I mean that really depends on the overall design I think. I think - as the condition might be processed in Max it might also be more readable to do those things there.

EDIT: Well, this could be interesting if you are working with patches distributed over several computers - in such cases CPU might be tight and also the network communication might already be pretty intense so that it might be good to not send information first to one place to reroute it there but to do it in the place it is generated. (Over the last years I was working with tracking systems which generated a huge amount of information and therefore it became really necessary to only sent the information that was actually need in one place to keep the system from getting stressed ....)

Sorry for the confusion.

best

[jim]

Ok,

>> Yes. I just bumped up uploadable image sizes to 1000x1000, 1MB total file size.>>

how? the image button in the message editor wants a link - no upload ...


There are two ways to submit images; by inserting an image link into a message (which is what you found), and by attaching an image. When you are editing a message, look down for the "manage attachments" button, there you can add images and zip files to your post. Images are limited to 1000 x 1000, 1MB in size. I have tweaked the board settings so that attached images are displayed inline.

Cheers,
Jim

[adamj]

+1 for OSC functionality

OSC hardware that I use: monome, iPhone (via touchOSC, OSCemote)
OSC software: Max/MSP, my own custom Ruby software

Things I would like to do with Numerology:

1) Trigger presets and control sequencing parameters via OSC messages from my hardware.

2) Generate sequencing patterns with my own software (I just posted about this over here: http://five12.net/showpost.php?p=572&postcount=9)

3) Control OSC-compatible synthesizers and effects, such as Future Audio Workshop's Circle Synth and MaxMSP patches, by generating sequenced OSC messages. And similarly, control synchronized generative graphics in Jitter, Quartz Composer, or Processing.

#1 and #2 would require Numerology to be an OSC listener, and #3 would require it to be an OSC generator.

For OSC generation I'm picturing something simple like a mononote sequencing module where I assign an address and port to the module and the value of the sliders is sent to the address (I realize the translation to OSC might be outside of the module, I'm just thinking about the use case). So I'd set port=5555 and address=/mysynth/filter/cutoff, and if the slider value if 0.5 then it would send /mysynth/filter/cutoff 0.5 to UDP port 5555. Slider ranges would typically go from 0.0 to 1.0 instead of say 0 to 127 like in MIDI. If I want to talk to another address I'd probably just setup another stack with an independent sequencer, but Numerology seems flexible enough that there would be reasons to put multiple OSC generators (each with their own address?) in a single stack.

For OSC listening, I think Circle Synth (http://www.futureaudioworkshop.com/circle/) provides a really good example of how OSC listening support should be done. If I twiddle a knob in that program, I can see what OSC message it listens to. Furthermore, it sends that OSC message on the outbound port when I twiddle the knob so I can build my own MIDI-learn-style system around this (although I could do without that functionality, or at least make it optional to save some CPU/network traffic). Circle is free to download and try (it goes out of tune after 10 minutes or so), so Jim you might want to play around with it for some ideas.

I'd also like to point out that once Numerology supports both OSC listening and generation, then you can have multiple people running Numerology on a network and interacting with each other, influencing each other's sequences and what not. That might lead to complete chaos but it could be fertile ground for some live sequencing improv performances.

What else... earlier in the thread Jim mentioned:
- Or, you may have an OSC device that sends messages, and you want Numerology to be able to detect them and extract useful information. For that case, you would want an OSC equivalent of the MIDIToCv module.
I'm not sure what you mean by "extract useful information", but I'd suggest rather than try to make some big complex OSC translator/mapping component you could just start with some predefined set of addresses (like Circle synth) and leave it up to the user to speak that protocol. If someone needs to map the stuff coming out of their iPhone they can use something like OSCulator. I'm not saying you should never do a built in translator/mapping component, but you could get a very useful first pass implementation by just having some predefined addresses that Numerology responds to. On the other hand, if you want to build on top of your CV system then maybe it makes sense. Ok I should probably stop now, I don't know how Numerology works under the hood...

Hope these ideas are helpful.

[jim]

Yes -- they are helpful. Thanks for the detailed post!

Cheers,
Jim

[sonomute]

but I'd suggest rather than try to make some big complex OSC translator/mapping component you could just start with some predefined set of addresses (like Circle synth) and leave it up to the user to speak that protocol. If someone needs to map the stuff coming out of their iPhone they can use something like OSCulator

I`m totally disagree with this.
In this case you will be able to use Numerology as a source of OSC data but not be able to control Numerology with OSC (and the main point of implementing OSC in NUM in my opinion is all those wonderful weird controllers like monome, lemour and a rest...)

Of course we can use Osculator, but what the point of OSC in Num if we still converting OSC to midi? And by the way, if someone needs to map the stuff coming whateverfrom to their Circle synth he can just use MIDI protocol, it working very good with this synth...:)))))

So, please, if there will be OSC in Num, just let it be proper way, don`t ask only for yourself...we all have different needs and tasks,don`t be so selfish.

Thank you.

[ehdyn]

Hoping for high band-width communication with SC and Reaktor + alternative controller support.

[jim]

I`m totally disagree with this.
In this case you will be able to use Numerology as a source of OSC data but not be able to control Numerology with OSC (and the main point of implementing OSC in NUM in my opinion is all those wonderful weird controllers like monome, lemour and a rest...)

More likely than not, there will be three options:

- A pair of 'plain but flexible' OSC In & OSC Out modules that essentially enable you to convert CV streams to OSC messages and back. You define the message.
- A "fixed" set of messages that covers all parameters for all modules in a project. This may also include some 'edit' commands (like add module, show stack, etc.)
- Some sort of 'learn' mode to make it easy to assign automate-able parameters to incoming OSC messages -- just like the MIDI learn facility.

That seems to cover all likely uses. The first option will be implemented first, then the others will follow.

Cheers,
Jim

[adamj]

I`m totally disagree with this.
In this case you will be able to use Numerology as a source of OSC data but not be able to control Numerology with OSC (and the main point of implementing OSC in NUM in my opinion is all those wonderful weird controllers like monome, lemour and a rest...)


I think you misunderstood. I asked for Numerology to support listening to OSC *and* sending OSC messages. If it can listen to OSC messages than it would support monome, lemur, etc. I definitely want this too! And if it can generate messages than it can control synchronized generative graphics and Max/MSP patches. Plus, you need to send back OSC messages to update the interface on a monome and a lemur. Controlling things with Numerology is just as important as letting it be controlled IMHO.


Of course we can use Osculator, but what the point of OSC in Num if we still converting OSC to midi?


Osculator supports OSC forwarding where you can map things from one address to another. No MIDI involved in this case. But avoiding another program would be preferable...


So, please, if there will be OSC in Num, just let it be proper way, don`t ask only for yourself...we all have different needs and tasks,don`t be so selfish.


Hmm, I genuinely want Numerology to have good OSC support useful to everyone. Jim wanted people's input on how they use OSC so he can make informed decisions, and I thought I was being helpful by taking to time to write up all that info.

Anyway, I don't disagree with you. The only reason I suggested he doesn't build a complex mapper *at first* is so he could provide basic OSC support sooner and we could give feedback to help make it even better. However, I concede that suggestion was not a good one. I am a Numerology newbie still learning the program, and I can see now that it would be best to have something to map arbitrary OSC messages to CV values.

Luckily Jim knows what he's doing. He said the first thing he'll provide is "A pair of 'plain but flexible' OSC In & OSC Out modules that essentially enable you to convert CV streams to OSC messages and back. You define the message." I think this covers both our needs. So it's all good :)

[adamj]

A pair of 'plain but flexible' OSC In & OSC Out modules that essentially enable you to convert CV streams to OSC messages and back. You define the message.


Hey Jim,
I think one of the rough spots with this feature will be how to map OSC messages to indexed parameters.

To give you an idea, the program TouchOSC for iPhone has a series of sliders that sends messages like this:
/multifader/1 value
/multifader/2 value
...
/multifader/16 value

I think the Lemur may do something similar (can anyone verify?)

It would make a lot of sense to be able to map input like that to the StepValue for a gate/interval/etc sequencer.

I guess at first we might have to setup 16 separate OSC input and ParamMod modules, one for each index? In the future, if there was a way to do this with one module, that would be much better. Maybe the incoming OSC address could be set to /multifader/$INDEX or something like that.

I wanted to bring it up now in case it affects how you're going to implement OSC features.

[jim]

Certainly using a plain OSC In/Out module to do sequencer steps would be tedious, thus the presence of the two other options. The best option, if you were using TouchOSC on the iPhone, would be the learn mode, or the "direct param" mode. In the latter case, the messages would be something like:
/stack1/MonoNote/PitchStep/1 <value>
/stack1/MonoNote/PitchStep/2 <value>
/stack1/MonoNote/PitchStep/3 <value>
etc...

Cheers,
Jim

(and yes, I do have an iPhone...)

[Sjoerd]

+1 for OSC support. :-) That would be AWESOME. :)

• What existing hardware and software do you have that supports OSC?
• How do you use OSC in your setup already?
• What kind of OSC support would you like to see in Numerology?
I'm using multiple iPhone / iPod Touch devices, as controllers, with Mrmr (free, open source!) mostly, though I occasionally also use other apps (OSCemote, TouchOSC) for that. Good to see others here also using iPhones. :) While I'm quite comfortable with the multitude of existing generic solutions, perhaps we can think of some iPhoneOS/Numerology specific controller patches for / extensions to existing apps, or even a standalone app? (I have the SDK installed, and some good friends within the iPhone developer community. <puts thinking about this on to-do list>

I'm also working with Pure data, Max/MSP, where I use custom patches for manipulating the data streams from the controller devices, then sending manipulated data streams out (most often as MIDI, but preferably in OSC to maintain high speed, bandwidth, and especially resolution) to instruments / effects (both virtual and physical ones). So yeah, I'm all for native OSC support in audio/music apps.

I guess the main hurdle for a simple practical implementation is the flexible namespacing in OSC. If it takes some common conventions (i.e. reduction in flexibility) to make it work, I'm fine with that. If complex setups take a lot of tedious work to set up, no problem either. Whatever works.

I'll be happy to post more extensive information on (my) use cases, and help testing if needed. Need to read up bit more on what has been discussed already and get more comfortable with N2 before I start blabbering complete nonsense and make you all hate me. :D

[jim]

I'll be happy to post more extensive information on (my) use cases, and help testing if needed. Need to read up bit more on what has been discussed already and get more comfortable with N2 before I start blabbering complete nonsense and make you all hate me. :D

I should have a pro version beta sometime this summer with OSC support...

Cheers,
Jim

[SteveElbows]

I would like to use this with lemur, touchosc and both visualising & controlling stuff with quartz composer.

Im not exactly an advanced numerology user so I would initially be looking, for example, to have every aspect of the state of the MonoNote module sent & received via OSC.

[jim]

Here's a quick OSC update to summarize stuff I've previously posted, and to update some information:

I'll be adding extensive OSC support to the "pro" version of Numerology. I hope to have the first beta of that available in 5-8 weeks. Three kinds of support are planned:

- an OSC Learn mode, similar to the MIDI learn mode already in place.
- a pair of OSC Input and Output modules for direct generation of osc messages (from sequences or other CV sources).
- direct OSC command access to all modulate-able module parameters, with
easy to read messages, something like:
"/N/StackName/ModName/ParamId <value>"

I have a prototype implementation of OSC learn already running. I've tested it with TouchOSC on my iPhone and is pretty cool. :)

Cheers,
Jim

[heyhellohowareyou]

Here is one more vote for OSC support for tight Lemur integration! :D