Hi everyone,
I've been considering the idea of playing around with livenoisetools:
http://www.pawfal.org/Software/livenoisetools/
...just for fun. One of the problems I've come across is how to play "it". The software is written to receive nothing but osc messages. For example, the synthesizer, itchy, needs this to play a note (from the doc):
/play iiiffffi [timeseconds timefrac ID frequency slidefreq volume pan message] Plays a note at the given time (in ntp format), on the given instrument with the given parameters. if the time is set to 0,0 it will ignore the time and play the note asap. The message parameter is interpreted as a char and if set to a "O" will cause an accent note to be triggered. this will be replaced by something more sane soon :) The slidefrequency gives a frequency to start sliding to (speed is defined by instrument modify commands for voices that support it).
I'm wondering if it would be possible to use pd as a bridge between my midi keyboard and this software, i.e. I play a middle C and the correct messages would be translated to the software.
Is this possible in pd? (Currently I have access to vanilla...) If so, can you point me to which objects I need to be looking for?
If this isn't possible, do you have any suggestions as to a better method for doing this?
I appreciate the help,
Josh
Josh Lawrence http://www.hardbop200.com
Hi Josh,
Welcome to the wonderful world of message construction in Pd. Your most basic chain will be to use [notein] to get MIDI notes and then [pack] to pack together the kind of OSC message the synth expects. This can all be done in Vanilla Pd.
More complicated messages can be done in a wide and weird number of ways. Best to look at the list-abs abstractions in Pd-Extended.
However, you will need Extended or the individual OSC objects on your system to communicate with an OSC application outside of Pd, either locally on your own machine or out on a network somewhere. Check the oscx help files in Extended. [sendOSC] is the particular object you'll need to send to the other OSC client software.
best, Derek
Josh Lawrence wrote:
Hi everyone,
I've been considering the idea of playing around with livenoisetools:
http://www.pawfal.org/Software/livenoisetools/
...just for fun. One of the problems I've come across is how to play "it". The software is written to receive nothing but osc messages. For example, the synthesizer, itchy, needs this to play a note (from the doc):
/play iiiffffi [timeseconds timefrac ID frequency slidefreq volume pan message] Plays a note at the given time (in ntp format), on the given instrument with the given parameters. if the time is set to 0,0 it will ignore the time and play the note asap. The message parameter is interpreted as a char and if set to a "O" will cause an accent note to be triggered. this will be replaced by something more sane soon :) The slidefrequency gives a frequency to start sliding to (speed is defined by instrument modify commands for voices that support it).
I'm wondering if it would be possible to use pd as a bridge between my midi keyboard and this software, i.e. I play a middle C and the correct messages would be translated to the software.
Is this possible in pd? (Currently I have access to vanilla...) If so, can you point me to which objects I need to be looking for?
If this isn't possible, do you have any suggestions as to a better method for doing this?
I appreciate the help,
Josh
Derek Holzer wrote:
However, you will need Extended or the individual OSC objects on your system to communicate with an OSC application outside of Pd, either locally on your own machine or out on a network somewhere. Check the oscx help files in Extended. [sendOSC] is the particular object you'll need to send to the other OSC client software.
i agree with everything derek has said, but one thing: do NOT use oscx for OSC-communication. instead use mrpeach's net and osc libraries. [packOSC]+[udpsend] for sending osc [udpreceive]+[unpackOSC] for receiving osc
for the reasons see the archives of this list...
fgmasdr IOhannes
Hello Derek and IOHannes,
Thank you so much for the advice, I will definitely check all of this out.
b/t/w, is there an IRC room that pd'ers hang out in that is generally welcome to newbies?
Thanks again!
2009/7/9 IOhannes m zmölnig zmoelnig@iem.at:
fgmasdr
Josh
I knew somebody would have to complicate my simple, straightforward answer...
Why hasn't somebody made this the "default" set of OSC objects in Extended by now then? Or perhaps replaced the original oscx libraries with these in a non-breaking way? And why is it split into two different libs?
Couldn't these objects be wrapped to give the same name as the standard OSC objects, but with whatever "better" functionality the list gurus have decided they give? For n00bs, having to use two different non-standard/non-default libs is just super confusing, and distracts from the task at hand, which is not to goof around with configuring Pd and/or importing libs but to communicate between two OSC apps.
Also for writing the FLOSS Manual, a "correct" chapter on OSC now means either Path or [import] has to be discussed first, and then two different libs must be used. Big fat bummer!
Can anybody say (in a few sentences rather than a lengthly thread) why one wouldn't use the simpler OSC objects for such a simple task? Points for brevity, nobody gets paid by the word around here ;-)
D.
IOhannes m zmölnig wrote:
i agree with everything derek has said, but one thing: do NOT use oscx for OSC-communication. instead use mrpeach's net and osc libraries. [packOSC]+[udpsend] for sending osc [udpreceive]+[unpackOSC] for receiving osc
for the reasons see the archives of this list...
Derek Holzer wrote:
I knew somebody would have to complicate my simple, straightforward answer...
sorry: a simple, straightforward and misleading answer.
Why hasn't somebody made this the "default" set of OSC objects in Extended by now then? Or perhaps replaced the original oscx libraries with these in a non-breaking way?
oh, i have. i don't use Pd-extended, i don't know where i should have put these abstractions. iirc, i have also posted such a wrapper on this list.
And why is it split into two different libs?
what? osc and net? maybe, because it deals with 2 different topics?
and how do you notice that it is split into 2 "different" libs in PdX?
Couldn't these objects be wrapped to give the same name as the standard OSC objects,
ähm, what is the "standard OSC objects".
but with whatever "better" functionality the list gurus have decided they give?
it's not about "better" functionality. it's about a broken and unmaintained object that only works in the most simple cases vs. an actively maintained one. i hardly ever care for the "added" functionality (if by "added/additional/superfluous" you really mean "according to the OSC standard"), like having typetags. however, i do care for if an object will crash during performance or not.
For n00bs, having to use two different non-standard/non-default libs is just super confusing, and distracts from the task at hand, which is not to goof around with configuring Pd and/or importing libs but to communicate between two OSC apps.
i totally agree. this is why i don't understandd why anybody would recommend the outdated, non-maintained, broken choice of these 2 libs.
Also for writing the FLOSS Manual, a "correct" chapter on OSC now means either Path or [import] has to be discussed first, and then two different libs must be used. Big fat bummer!
?? when using oscx, you are using a library: so either Path or [import] (or better [declare]) have to be discussed first. so what's the difference to mrpeach's libs?
however, indeed you have to use 2 objects instead of just 1. big fat bummer!
Can anybody say (in a few sentences rather than a lengthly thread) why one wouldn't use the simpler OSC objects for such a simple task? Points for brevity, nobody gets paid by the word around here ;-)
crashes. osc-standards. ability to communicate with OSC-apps over udp/tcp/usb/...
mfgadr IOhannes
Hi again,
IOhannes m zmölnig wrote:
and how do you notice that it is split into 2 "different" libs in PdX?
My mistake, I thought there was a mrpeach net lib and a mrpeach osc lib.
Couldn't these objects be wrapped to give the same name as the standard OSC objects,
ähm, what is the "standard OSC objects".
The ones people have used for a very long time in Pd (for me since 2002), which are loaded by default in Pd Extended and which do the job in a straightforward way.
when using oscx, you are using a library: so either Path or [import] (or better [declare]) have to be discussed first. so what's the difference to mrpeach's libs?
As I mentioned, they are not available by default.... which is the reason I brought this point up. I'm not trying to convince anyone to use outdated software, but I am interested in why it would get replaced in a non-compatible and slightly more complicated way.
however, indeed you have to use 2 objects instead of just 1. big fat bummer!
Yes it is, since it will take twice as long to explain how to use this system in the Pd FLOSS Manual. And that even leaves aside the fact that import, declare or whatever will also have to be explained in-line. See how complicated it gets? ;-)
Can anybody say (in a few sentences rather than a lengthly thread) why one wouldn't use the simpler OSC objects for such a simple task?
crashes. osc-standards. ability to communicate with OSC-apps over udp/tcp/usb/...
Thank you. Your brevity is greatly appreciated ;-)
Now can anyone tell me why the original oscx stuff can't just be transparently replaced? Or that at least the mrpeach stuff could be included in the startup of Pd Extended at least? This would make teaching/documenting the "new way" of OSC a hell of a lot easier!!!!
D.
Derek Holzer wrote:
Hi again,
hi
thanks for the plentiful use of ;-) to peace my mind...
IOhannes m zmölnig wrote:
and how do you notice that it is split into 2 "different" libs in PdX?
My mistake, I thought there was a mrpeach net lib and a mrpeach osc lib.
which in fact they should be. i would say it is a bug that they are both in a "mrpeach" library (i guess most people won't care whether martin has written them or whoelse; but they might like to have osc-related or net-related objects)
Couldn't these objects be wrapped to give the same name as the standard OSC objects,
ähm, what is the "standard OSC objects".
The ones people have used for a very long time in Pd (for me since 2002), which are loaded by default in Pd Extended
if i understand hans correctly, he is planning to remove all the "loaded by default" anyhow (which i think is not a bad thing).
when using oscx, you are using a library: so either Path or [import] (or better [declare]) have to be discussed first. so what's the difference to mrpeach's libs?
As I mentioned, they are not available by default.... which is the reason I brought this point up. I'm not trying to convince anyone to use outdated software, but I am interested in why it would get replaced in a non-compatible and slightly more complicated way.
actually they _are_ available by default in pd-extended: [mrpeach/packOSC] and [mrpeach/udpsend] will just create (not that i very much like this the way it is; i would so much prefer [osc/packOSC] and [net/udpsend])
no need to know anything about libraries, paths, loading-by-default, and what-not.
however, indeed you have to use 2 objects instead of just 1. big fat bummer!
Yes it is, since it will take twice as long to explain how to use this system in the Pd FLOSS Manual. And that even leaves aside the fact that import, declare or whatever will also have to be explained in-line. See how complicated it gets? ;-)
at least i think that when people are reading the tutorial they should have an idea about how to connect 2 objects, and how to interact with these objects independently.
as for libraries see my remark above alternatively: i guess the tutorials are not self-contained (e.g. you can expect the user to already having read the other tutorial where they are tought to connect objects), so you can also schedule the "library loading tutorial" before the OSC tutorial.
Now can anyone tell me why the original oscx stuff can't just be transparently replaced?
it's easy (apart from the crashes). it's about creating an abstraction out of about 5 objects and 2 message-boxes. i leave this as an exercise for the adept user.
Or that at least the mrpeach stuff could be included in the startup of Pd Extended at least? This would make teaching/documenting the "new way" of OSC a hell of a lot easier!!!!
or at least remove oscx from the startup. this would make teaching the "old way" less preferable :-)
fgmasdr IOhannes
Howdy,
IOhannes m zmölnig wrote:
thanks for the plentiful use of ;-) to peace my mind...
OOOHHHHHHMMMMMMMMMMM.........
if i understand hans correctly, he is planning to remove all the "loaded by default" anyhow (which i think is not a bad thing).
This doesn't give me any peace of mind at all. What a terrible idea! But I guess most people in free software really can't get over the idea of spending all day compiling and configuring their applications before they can enjoy using them ;-)
alternatively: i guess the tutorials are not self-contained (e.g. you can expect the user to already having read the other tutorial where they are tought to connect objects), so you can also schedule the "library loading tutorial" before the OSC tutorial.
Actually the tutorials *should* be as self-encapsulated as possible, so that they can be "remixed" between different manuals to make your own custom one. So stuff like "import" and "declare" etc etc would have to be explained in-line, just in case someone wants to make a manual about how to connect two different FLOSS apps via OSC, for example....
D.
Derek Holzer wrote:
Howdy,
IOhannes m zmölnig wrote:
thanks for the plentiful use of ;-) to peace my mind...
OOOHHHHHHMMMMMMMMMMM.........
if i understand hans correctly, he is planning to remove all the "loaded by default" anyhow (which i think is not a bad thing).
This doesn't give me any peace of mind at all. What a terrible idea! But I guess most people in free software really can't get over the idea of spending all day compiling and configuring their applications before they can enjoy using them ;-)
do not confuse "loaded by default" with "included/compiled/available". mrpeach's objects _are_ available in any Pd-extended for ages. they are just not added to the path.
alternatively: i guess the tutorials are not self-contained (e.g. you can expect the user to already having read the other tutorial where they are tought to connect objects), so you can also schedule the "library loading tutorial" before the OSC tutorial.
Actually the tutorials *should* be as self-encapsulated as possible, so
but still there are basics that have to be covered. you don't explain how to install Pd-extended in the OSC-tutorial (yo udo that in the installation-tutorial).
(but then i see that you _do_ explain the concept of hot&cold inlets in the "step sequencer" tutorial...hmm)
that they can be "remixed" between different manuals to make your own custom one. So stuff like "import" and "declare" etc etc would have to be explained in-line, just in case someone wants to make a manual about how to connect two different FLOSS apps via OSC, for example....
hmm, but then isn't this "remix" idea _exactly_ about this: just create a "library loading" tutorial and remix it into the osc-tutorial...
mfsdg.as IOhannes
IOhannes m zmölnig wrote:
actually they _are_ available by default in pd-extended: [mrpeach/packOSC] and [mrpeach/udpsend] will just create (not that i very much like this the way it is; i would so much prefer [osc/packOSC] and [net/udpsend])
Well can you just go ahead and do that please? I don't think I have write access to the whole externals tree. In externals/ just move mrpeach/net to /net and mrpeach/osc to /osc. I think it's time...
Martin
Martin Peach wrote:
IOhannes m zmölnig wrote:
actually they _are_ available by default in pd-extended: [mrpeach/packOSC] and [mrpeach/udpsend] will just create (not that i very much like this the way it is; i would so much prefer [osc/packOSC] and [net/udpsend])
Well can you just go ahead and do that please? I don't think I have write access to the whole externals tree. In externals/ just move mrpeach/net to /net and mrpeach/osc to /osc. I think it's time...
i don't think it is necessarily a bad idea to have the source-code structured as-is (e.g. in externals/mrpeach/osc), only on the installation-side it doesn't make sense....
currently i'm a bit limited in time (preparing for sao paolo and things...), so i won't do that _now_.
oh, and btw, you do have full access to the entire svn-tree (no access-control for svn on sourceforge) - it's mainly a matter of well-behaving to not commit things to parts where you are not "expected" to.
fgmasdr IOhannes
As suggests Derek, it would be nice to have some parts of the help reorganized. For exemple, the sound could be like this : I) sound i) oscillators a) purepd … b) externals … ii) filters a) purepd … b) externals …
It is just an exemple, there is certainly better. And it will be useful for the beginner and the pro. For the network, this will be the same with [netsend] [netreceive] [udpsend] [udpreceive] [packOSC] [routeOSC] [oggcast~] [oggamp~] etc. etc. Have you remarks ? ++
Jack
Le jeudi 09 juillet 2009 à 20:50 +0200, Derek Holzer a écrit :
I knew somebody would have to complicate my simple, straightforward answer...
Why hasn't somebody made this the "default" set of OSC objects in Extended by now then? Or perhaps replaced the original oscx libraries with these in a non-breaking way? And why is it split into two different libs?
Couldn't these objects be wrapped to give the same name as the standard OSC objects, but with whatever "better" functionality the list gurus have decided they give? For n00bs, having to use two different non-standard/non-default libs is just super confusing, and distracts from the task at hand, which is not to goof around with configuring Pd and/or importing libs but to communicate between two OSC apps.
Also for writing the FLOSS Manual, a "correct" chapter on OSC now means either Path or [import] has to be discussed first, and then two different libs must be used. Big fat bummer!
Can anybody say (in a few sentences rather than a lengthly thread) why one wouldn't use the simpler OSC objects for such a simple task? Points for brevity, nobody gets paid by the word around here ;-)
D.
IOhannes m zmölnig wrote:
i agree with everything derek has said, but one thing: do NOT use oscx for OSC-communication. instead use mrpeach's net and osc libraries. [packOSC]+[udpsend] for sending osc [udpreceive]+[unpackOSC] for receiving osc
for the reasons see the archives of this list...
Le jeudi 09 juillet 2009 à 21:35 +0200, IOhannes m zmölnig a écrit :
Jack wrote:
Have you remarks ? ++
just do it.
Nice one :) But really i don't know how to do this. But, in the first place, we have to agree on how to organize things. And yes, i could help. I think that it is time, seen the number of library included in Pd-ext, to reorganize the part Help (and so the rest) by well identified categories. I do not see how a beginner looking for an object to use OSC, have to go in 'reference' > 'mrpeach'. I think that something as 'reference' > 'network' > 'osc' would be more adapted. Otherwise so much look for a needle in a haystack. Maybe someone has already started to work on it ? ++
Jack
fgmasdr IOhannes
I agree there is a lot of super-hacker elite voodoo going on in Pd that makes it difficult to introduce yourself to it. Maybe you'd be interested in writing an OSC chapter for the Pd FLOSS Manual on this, as a way of making it clearer for everyone?
D.
Jack wrote:
Le jeudi 09 juillet 2009 à 21:35 +0200, IOhannes m zmölnig a écrit :
Jack wrote:
Have you remarks ? ++
just do it.
Nice one :) But really i don't know how to do this. But, in the first place, we have to agree on how to organize things. And yes, i could help. I think that it is time, seen the number of library included in Pd-ext, to reorganize the part Help (and so the rest) by well identified categories. I do not see how a beginner looking for an object to use OSC, have to go in 'reference' > 'mrpeach'. I think that something as 'reference' > 'network' > 'osc' would be more adapted. Otherwise so much look for a needle in a haystack. Maybe someone has already started to work on it ? ++
Jack
fgmasdr IOhannes
Derek Holzer wrote:
I knew somebody would have to complicate my simple, straightforward answer...
also i wonder, why nobody complained about my damnation of [sfplay] in favour of [readsf~]. is it just that by chance in this case nobody had set their bets on the slow runner?
fgamsdr IOhannes
Sorry IOhannes, I forgot the ;-) in the first line of my complaint.
;-)
D.
IOhannes m zmölnig wrote:
Derek Holzer wrote:
I knew somebody would have to complicate my simple, straightforward answer...
also i wonder, why nobody complained about my damnation of [sfplay] in favour of [readsf~]. is it just that by chance in this case nobody had set their bets on the slow runner?
fgamsdr IOhannes
-
Derek Holzer -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jack -
Josh Lawrence -
Martin Peach