Hi all,
does anybody know a way to send arbitrary length messages to arbitrary receivers? I would like to send OSC messages of variable length to pd, specifying the receiver in the first element of the message. It has to be completely dynamic as I want to create pd subpatchers dynamically, so OSCroute won't work.
It would be possible, if e.g. the send object allowed for a set message (or have a right inlet for setting the receiver), or if it was possible to use message boxes with Dollarsigns for arbitrary length messages.
Before patching pd's send I thought to better ask for a standard way to get this done.
Yours, Orm
On Thu, 10 Aug 2006, Orm Finnendahl wrote:
Hi all,
does anybody know a way to send arbitrary length messages to arbitrary receivers? I would like to send OSC messages of variable length to pd, specifying the receiver in the first element of the message. It has to be completely dynamic as I want to create pd subpatchers dynamically, so OSCroute won't work.
It would be possible, if e.g. the send object allowed for a set message (or have a right inlet for setting the receiver), or if it was possible to use message boxes with Dollarsigns for arbitrary length messages.
Before patching pd's send I thought to better ask for a standard way to get this done.
Hi Orm,
I recently had the same problem. There is an external send13 (in ext13) that accepts a set message. This solution is bad, because then you can't send "set" messages anymore. I think the best thing would be to have a second inlet to send, if you go that way it would be great if you could put your solution on the patch tracker.
Günter
PS: I couldnt find a standard way either ... maybe someone else knows.
Hi Günter,
my concerns are exactly the same as your's. My thoughts go along the following lines:
add a right inlet to send the way you suggest (which wouldn't break anything).
if send gets initialized without argument, the first element of a received list is the target. This could break things although it seems rather unlikely that anybody ever used send without arguments, as any message received in such an object would get discarded.
What do you think? I can apply the changes and post the patch against x_connective.c to the list (is that the way to go?)
-- Orm
Am 10. August 2006, 18:44 Uhr (+0200) schrieb geiger:
On Thu, 10 Aug 2006, Orm Finnendahl wrote:
Hi all,
does anybody know a way to send arbitrary length messages to arbitrary receivers? I would like to send OSC messages of variable length to pd, specifying the receiver in the first element of the message. It has to be completely dynamic as I want to create pd subpatchers dynamically, so OSCroute won't work.
It would be possible, if e.g. the send object allowed for a set message (or have a right inlet for setting the receiver), or if it was possible to use message boxes with Dollarsigns for arbitrary length messages.
Before patching pd's send I thought to better ask for a standard way to get this done.
Hi Orm,
I recently had the same problem. There is an external send13 (in ext13) that accepts a set message. This solution is bad, because then you can't send "set" messages anymore. I think the best thing would be to have a second inlet to send, if you go that way it would be great if you could put your solution on the patch tracker.
Günter
PS: I couldnt find a standard way either ... maybe someone else knows.
Hallo, Orm Finnendahl hat gesagt: // Orm Finnendahl wrote:
my concerns are exactly the same as your's. My thoughts go along the following lines:
add a right inlet to send the way you suggest (which wouldn't break anything).
if send gets initialized without argument, the first element of a received list is the target. This could break things although it seems rather unlikely that anybody ever used send without arguments, as any message received in such an object would get discarded.
We already have this functionality as externals (sprinkler) and as a message-based solution, so I don't see the reason for such a patch.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Thu, 10 Aug 2006, Frank Barknecht wrote:
Hallo, Orm Finnendahl hat gesagt: // Orm Finnendahl wrote:
my concerns are exactly the same as your's. My thoughts go along the following lines:
add a right inlet to send the way you suggest (which wouldn't break anything).
if send gets initialized without argument, the first element of a received list is the target. This could break things although it seems rather unlikely that anybody ever used send without arguments, as any message received in such an object would get discarded.
We already have this functionality as externals (sprinkler) and as a message-based solution, so I don't see the reason for such a patch.
Are you referring to the second proposal or to the whole patch ? While I think that it is probably better not to implement the sprinkler like behaviour, I think the second inlet would be a very welcome addition.
I don't think that it would be harmful, just considering that Miller is conservative in changing behaviour of objects it is more likely that the patch gets accepted if it only implements the second inlet.
As my example with the array receiver showed, there is no elegant solution without using externals.
But then, my case was certainly very special, the next time I would do it with a script from outside Pd.
Günter
Hallo, geiger hat gesagt: // geiger wrote:
On Thu, 10 Aug 2006, Frank Barknecht wrote:
We already have this functionality as externals (sprinkler) and as a message-based solution, so I don't see the reason for such a patch.
Are you referring to the second proposal or to the whole patch ? While I think that it is probably better not to implement the sprinkler like behaviour, I think the second inlet would be a very welcome addition.
I was referring to the whole patch, but thinking about it a bit more, I guess, the second inlet would indeed do no harm and could be handy sometimes. Basically it does the same as the "addsemi" message to a message box, but it probably is a bit faster.
The sprinkler-part of the patch is not needed then at all, as you could just split off the first element of an incoming list and route it to the second inlet of the new [send].
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, geiger hat gesagt: // geiger wrote:
I recently had the same problem. There is an external send13 (in ext13) that accepts a set message. This solution is bad, because then you can't send "set" messages anymore. I think the best thing would be to have a second inlet to send, if you go that way it would be great if you could put your solution on the patch tracker.
Actually I never in about 5 years of using Pd was desperately needing a renamable send (although I now know, how it's done, see other mail), so I'm really a bit wondering what use cases there are for settable senders, that could not be solved with other approaches - like [route].
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Am 10. August 2006, 19:20 Uhr (+0200) schrieb Frank Barknecht:
Actually I never in about 5 years of using Pd was desperately needing a renamable send (although I now know, how it's done, see other mail), so I'm really a bit wondering what use cases there are for settable senders, that could not be solved with other approaches - like [route].
Anything which has to get assigned dynamically. I'm currently connecting pd to supercollider, and want to create and access gui-objects or whatever from sclang. That not only makes a gui available to sc on linux but also takes advantage of both worlds (graphic editing and text/script-based programming) transparently.
-- Orm
On Thu, 10 Aug 2006, Frank Barknecht wrote:
Actually I never in about 5 years of using Pd was desperately needing a renamable send (although I now know, how it's done, see other mail), so I'm really a bit wondering what use cases there are for settable senders, that could not be solved with other approaches - like [route].
Actually I solved it with another approach, but the settable send would have been the elegant way. I do admit that my approach was brute force.
The problem was sending about 100 lists, each one of a different size (from 1 element to 100) to different receivers, the receivers were arrays (it was the cosinesum for the antialiased waveforms).
Have to check the solution you posted to Orm, but I ended up with hundred sends, as far as I can remember. Although you can build them programatically its a bit of a pain, and definitely everything else than elegant.
Günter
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 2006-08-10 at 19:20 +0200, Frank Barknecht wrote:
Hallo, geiger hat gesagt: // geiger wrote:
I recently had the same problem. There is an external send13 (in ext13) that accepts a set message. This solution is bad, because then you can't send "set" messages anymore. I think the best thing would be to have a second inlet to send, if you go that way it would be great if you could put your solution on the patch tracker.
Actually I never in about 5 years of using Pd was desperately needing a renamable send (although I now know, how it's done, see other mail), so I'm really a bit wondering what use cases there are for settable senders, that could not be solved with other approaches - like [route].
i don't quite have the same experience as frank, but i also never *had* to use a settable send...
btw: there is one:
[; $1 $2(
although it has the disadvantage of a fixed number of elements....
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
On Thu, 2006-08-10 at 19:20 +0200, Frank Barknecht wrote:
Actually I never in about 5 years of using Pd was desperately needing a renamable send (although I now know, how it's done, see other mail), so I'm really a bit wondering what use cases there are for settable senders, that could not be solved with other approaches - like [route].
there is one:
[; $1 $2(
Actually I'm an idiot: I am using that one *all of the time*, for example in RRADical, and of course it's a settable send.
What I meant to write was: I never needed a settable *receiver*, but that is a different issue.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
hi orm,
On Thu, 2006-08-10 at 18:03 +0200, Orm Finnendahl wrote:
It would be possible, if e.g. the send object allowed for a set message (or have a right inlet for setting the receiver), or if it was
sounds to me like a job for either send13 from ext13 or forward from cyclone ...
hth ... tim
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
Your mind will answer most questions if you learn to relax and wait for the answer. William S. Burroughs
Orm Finnendahl wrote:
Hi all,
does anybody know a way to send arbitrary length messages to arbitrary receivers? I would like to send OSC messages of variable length to pd, specifying the receiver in the first element of the message. It has to be completely dynamic as I want to create pd subpatchers dynamically, so OSCroute won't work.
It would be possible, if e.g. the send object allowed for a set message (or have a right inlet for setting the receiver), or if it was possible to use message boxes with Dollarsigns for arbitrary length messages.
Before patching pd's send I thought to better ask for a standard way to get this done.
hi,
there is stil no "standard" way to get this done. either use [sprinkler] (moocow) or [iem_s] (iemlib) or ...
fmga.dr IOhannes
[iem_send] seems to make best sense to me, a normal send with a right inlet to set the destination. It's worked reliably for me in several patches.
I wanted an audio equivient recently and ended up using [demux~] Has anyone a better solution for dynamically routable audio signals?
On Thu, 10 Aug 2006 18:53:19 +0200 IOhannes m zmoelnig zmoelnig@iem.at wrote:
Orm Finnendahl wrote:
Hi all,
does anybody know a way to send arbitrary length messages to arbitrary receivers? I would like to send OSC messages of variable length to pd, specifying the receiver in the first element of the message. It has to be completely dynamic as I want to create pd subpatchers dynamically, so OSCroute won't work.
It would be possible, if e.g. the send object allowed for a set message (or have a right inlet for setting the receiver), or if it was possible to use message boxes with Dollarsigns for arbitrary length messages.
Before patching pd's send I thought to better ask for a standard way to get this done.
hi,
there is stil no "standard" way to get this done. either use [sprinkler] (moocow) or [iem_s] (iemlib) or ...
fmga.dr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, 11 Aug 2006, padawan12 wrote:
I wanted an audio equivient recently and ended up using [demux~] Has anyone a better solution for dynamically routable audio signals?
throw~ and receive~ are both setable with a "set" message.
Günter
On Thu, 10 Aug 2006 18:53:19 +0200 IOhannes m zmoelnig zmoelnig@iem.at wrote:
Orm Finnendahl wrote:
Hi all,
does anybody know a way to send arbitrary length messages to arbitrary receivers? I would like to send OSC messages of variable length to pd, specifying the receiver in the first element of the message. It has to be completely dynamic as I want to create pd subpatchers dynamically, so OSCroute won't work.
It would be possible, if e.g. the send object allowed for a set message (or have a right inlet for setting the receiver), or if it was possible to use message boxes with Dollarsigns for arbitrary length messages.
Before patching pd's send I thought to better ask for a standard way to get this done.
hi,
there is stil no "standard" way to get this done. either use [sprinkler] (moocow) or [iem_s] (iemlib) or ...
fmga.dr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Orm Finnendahl wrote:
Hi all,
does anybody know a way to send arbitrary length messages to arbitrary receivers? I would like to send OSC messages of variable length to pd, specifying the receiver in the first element of the message. It has to be completely dynamic as I want to create pd subpatchers dynamically, so OSCroute won't work.
Did you try my routeOSC? It is like OSCroute but has a set method which can be used to change the route symbols. It can be found here: http://pure-data.iem.at/Members/martinrp/ Martin
It would be possible, if e.g. the send object allowed for a set message (or have a right inlet for setting the receiver), or if it was possible to use message boxes with Dollarsigns for arbitrary length messages.
Before patching pd's send I thought to better ask for a standard way to get this done.
Yours, Orm
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hey Martin,
Will you put these externals in CVS? Or are your worried about conflicts and/or stability?
I'd like to see em in PD-extended.
.b.
Martin Peach wrote:
Orm Finnendahl wrote:
Hi all,
does anybody know a way to send arbitrary length messages to arbitrary receivers? I would like to send OSC messages of variable length to pd, specifying the receiver in the first element of the message. It has to be completely dynamic as I want to create pd subpatchers dynamically, so OSCroute won't work.
Did you try my routeOSC? It is like OSCroute but has a set method which can be used to change the route symbols. It can be found here: http://pure-data.iem.at/Members/martinrp/ Martin
It would be possible, if e.g. the send object allowed for a set message (or have a right inlet for setting the receiver), or if it was possible to use message boxes with Dollarsigns for arbitrary length messages.
Before patching pd's send I thought to better ask for a standard way to get this done.
Yours, Orm
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
B. Bogart wrote:
Hey Martin,
Will you put these externals in CVS? Or are your worried about conflicts and/or stability?
I'd like to but last time I tried I didn't seem to have write permission. Is the cvs globally writeable by every developer or do I need to ask for permission someplace? I would like to add folders named net and osc in externals. (I also have a bandlimited pwm oscillator that I'm not sure where it should go...)
Martin
I'd like to see em in PD-extended.
.b.
Martin Peach wrote:
Orm Finnendahl wrote:
Hi all,
does anybody know a way to send arbitrary length messages to arbitrary receivers? I would like to send OSC messages of variable length to pd, specifying the receiver in the first element of the message. It has to be completely dynamic as I want to create pd subpatchers dynamically, so OSCroute won't work.
Did you try my routeOSC? It is like OSCroute but has a set method which can be used to change the route symbols. It can be found here: http://pure-data.iem.at/Members/martinrp/ Martin
It would be possible, if e.g. the send object allowed for a set message (or have a right inlet for setting the receiver), or if it was possible to use message boxes with Dollarsigns for arbitrary length messages.
Before patching pd's send I thought to better ask for a standard way to get this done.
Yours, Orm
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Martin,
I think as long as you are added as a developer to the pure-data project you can write to CVS, you have to checkout as a developer rather than anonymous though.
Seems most people put externals in a folder of thier own name. other externals could fit into the catagory of "net" so until we deal with the catagoriesforexterals mess probably best to just use your name and put it all in there.
Let us know if it still does not work...
.b.
Martin Peach wrote:
B. Bogart wrote:
Hey Martin,
Will you put these externals in CVS? Or are your worried about conflicts and/or stability?
I'd like to but last time I tried I didn't seem to have write permission. Is the cvs globally writeable by every developer or do I need to ask for permission someplace? I would like to add folders named net and osc in externals. (I also have a bandlimited pwm oscillator that I'm not sure where it should go...)
Martin
I'd like to see em in PD-extended.
.b.
Martin Peach wrote:
Orm Finnendahl wrote:
Hi all,
does anybody know a way to send arbitrary length messages to arbitrary receivers? I would like to send OSC messages of variable length to pd, specifying the receiver in the first element of the message. It has to be completely dynamic as I want to create pd subpatchers dynamically, so OSCroute won't work.
Did you try my routeOSC? It is like OSCroute but has a set method which can be used to change the route symbols. It can be found here: http://pure-data.iem.at/Members/martinrp/ Martin
It would be possible, if e.g. the send object allowed for a set message (or have a right inlet for setting the receiver), or if it was possible to use message boxes with Dollarsigns for arbitrary length messages.
Before patching pd's send I thought to better ask for a standard way to get this done.
Yours, Orm
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Post a transcript and we'll take it from there. I want to get my
hands on your code too, lots of good stuff!
.hc
On Aug 10, 2006, at 8:47 PM, B. Bogart wrote:
Hi Martin,
I think as long as you are added as a developer to the pure-data
project you can write to CVS, you have to checkout as a developer rather than anonymous though.Seems most people put externals in a folder of thier own name. other externals could fit into the catagory of "net" so until we deal
with the catagoriesforexterals mess probably best to just use your name and put it all in there.Let us know if it still does not work...
.b.
Martin Peach wrote:
B. Bogart wrote:
Hey Martin,
Will you put these externals in CVS? Or are your worried about
conflicts and/or stability?I'd like to but last time I tried I didn't seem to have write permission. Is the cvs globally writeable by every developer or do I need to ask for permission someplace? I would like to add folders
named net and osc in externals. (I also have a bandlimited pwm
oscillator that I'm not sure where it should go...)Martin
I'd like to see em in PD-extended.
.b.
Martin Peach wrote:
Orm Finnendahl wrote:
Hi all,
does anybody know a way to send arbitrary length messages to
arbitrary receivers? I would like to send OSC messages of variable length
to pd, specifying the receiver in the first element of the message. It
has to be completely dynamic as I want to create pd subpatchers
dynamically, so OSCroute won't work.Did you try my routeOSC? It is like OSCroute but has a set
method which can be used to change the route symbols. It can be found here: http://pure-data.iem.at/Members/martinrp/ MartinIt would be possible, if e.g. the send object allowed for a set message (or have a right inlet for setting the receiver), or if
it was possible to use message boxes with Dollarsigns for arbitrary
length messages.Before patching pd's send I thought to better ask for a
standard way to get this done.Yours, Orm
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Will you put these externals in CVS? Or are your worried about conflicts and/or stability?
I'd like to but last time I tried I didn't seem to have write permission. Is the cvs globally writeable by every developer
not globally. i think the only restricticted branches are HEAD/MAIN. and maybe a couple of others which are auto-synched from remote repositories
if you have an :ext acct and can't create a dir in externals/, its a bug...
Martin,
Were you able to do a check-in?
.b.
carmen wrote:
Will you put these externals in CVS? Or are your worried about conflicts and/or stability?
I'd like to but last time I tried I didn't seem to have write permission. Is the cvs globally writeable by every developer
not globally. i think the only restricticted branches are HEAD/MAIN. and maybe a couple of others which are auto-synched from remote repositories
if you have an :ext acct and can't create a dir in externals/, its a bug...
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
B. Bogart wrote:
Martin,
Were you able to do a check-in?
I just did some adds and commits...In the directory mrpeach there should be net, osc and sqosc~ net contains the tcp and udp net objects. osc contains routeOSC, packOSC and unpackOSC sqosc~ contains the bandlimited pwm object. Help files are also included. I guess I need to do the makefiles next, but they are simple to compile, with no dependencies besides pd and math.
Martin
.b.
carmen wrote:
Will you put these externals in CVS? Or are your worried about conflicts and/or stability?
I'd like to but last time I tried I didn't seem to have write permission. Is the cvs globally writeable by every developer
not globally. i think the only restricticted branches are HEAD/MAIN. and maybe a couple of others which are auto-synched from remote repositories
if you have an :ext acct and can't create a dir in externals/, its a bug...
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Aug 16, 2006, at 4:30 PM, Martin Peach wrote:
B. Bogart wrote:
Martin,
Were you able to do a check-in?
I just did some adds and commits...In the directory mrpeach there
should be net, osc and sqosc~ net contains the tcp and udp net objects. osc contains routeOSC, packOSC and unpackOSC sqosc~ contains the bandlimited pwm object. Help files are also included. I guess I need to do the makefiles
next, but they are simple to compile, with no dependencies besides
pd and math.
I just made a small commit to your code, I hope you don't mind. I
just added one missing line to some of the net .c files so that they
would compile on Mac OS X:
#include <sys/types.h>
Also, I added mrpeach to the Pd-extended build system and added a
Makefile to externals/mrpeach. This Makefile works on GNU/Linux, Mac
OS X, and Windows/MinGW without modification. Feel free to replace
it or edit it, of course its your code, but I think it'll work well
for you. The "mrpeach" targets are in externals/Makefile, so if you
add examples or a manual, you can have them automatically installed
by uncommenting some stuff there.
One last thing, just like Java or C++, with Pd, the classes should be
in a file named exactly like the class. So the "x_net_" should be
stripped off. This makes building much easier, as well as making
things generally neat.
.hc
Martin
.b.
carmen wrote:
Will you put these externals in CVS? Or are your worried about
conflicts and/or stability?I'd like to but last time I tried I didn't seem to have write
permission. Is the cvs globally writeable by every developernot globally. i think the only restricticted branches are HEAD/ MAIN. and maybe a couple of others which are auto-synched from
remote repositoriesif you have an :ext acct and can't create a dir in externals/,
its a bug...
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
On Thu, 17 Aug 2006, Hans-Christoph Steiner wrote:
One last thing, just like Java or C++, with Pd, the classes should be in a file named exactly like the class.
There's no such requirement in C++.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Aug 17, 2006, at 2:10 AM, Mathieu Bouchard wrote:
On Thu, 17 Aug 2006, Hans-Christoph Steiner wrote:
One last thing, just like Java or C++, with Pd, the classes should
be in a file named exactly like the class.There's no such requirement in C++.
There is also no such requirement in Java, but in both languages, its
considered standard practice, and good for your sanity.
.hc
There is no way to peace, peace is the way. -A.J. Muste
On Fri, 18 Aug 2006, Hans-Christoph Steiner wrote:
On Aug 17, 2006, at 2:10 AM, Mathieu Bouchard wrote:
There's no such requirement in C++.
There is also no such requirement in Java,
There is such a requirement implemented by most Java compilers and classloaders, that for a class to be public, it should have the same name as the file it's in. The requirement isn't in the language (in the sense of grammar and semantics), instead it's in the language (in the sense of runtime environment).
its considered standard practice,
by whom?
and good for your sanity.
Oh, that must be why I'm insane. Go smoke banana peels.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Fri, 2006-08-18 at 00:08 -0400, Hans-Christoph Steiner wrote:
On Aug 17, 2006, at 2:10 AM, Mathieu Bouchard wrote:
On Thu, 17 Aug 2006, Hans-Christoph Steiner wrote:
One last thing, just like Java or C++, with Pd, the classes should
be in a file named exactly like the class.There's no such requirement in C++.
There is also no such requirement in Java, but in both languages, its
considered standard practice, and good for your sanity.
i wouldn't try to implement the tr1 typetags with one file per class ...
t
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
Happiness is a byproduct of function, purpose, and conflict; those who seek happiness for itself seek victory without war. William S. Burroughs
On Fri, 18 Aug 2006, Tim Blechmann wrote:
On Fri, 2006-08-18 at 00:08 -0400, Hans-Christoph Steiner wrote:
There is also no such requirement in Java, but in both languages, its considered standard practice, and good for your sanity.
i wouldn't try to implement the tr1 typetags with one file per class ...
What's that?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Fri, 2006-08-18 at 04:19 -0400, Mathieu Bouchard wrote:
On Fri, 18 Aug 2006, Tim Blechmann wrote:
On Fri, 2006-08-18 at 00:08 -0400, Hans-Christoph Steiner wrote:
There is also no such requirement in Java, but in both languages, its considered standard practice, and good for your sanity.
i wouldn't try to implement the tr1 typetags with one file per class ...
What's that?
didn't have my first coffee, yet ... i meant type traits
www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1745.pdf
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
Every word is like an unnecessary stain on silence and nothingness Samuel Beckett
On Fri, 18 Aug 2006, Tim Blechmann wrote:
i wouldn't try to implement the tr1 typetags with one file per class ...
didn't have my first coffee, yet ... i meant type traits www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1745.pdf
Yeah, and every case of writing one-liner classes, e.g. most Exception classes (have empty bodies).
Small purely abstract classes (interfaces) are also annoying to have in separate files.
The "One class per file" rule is a kind of placebo for those who don't know enough means of keeping their code clean. That, or company policy, or working in a language that doesn't support putting two classes in one file (e.g. Pd).
The issue is moot if there are means to handle large numbers of files as efficiently as what can be done with a single file in an ordinary text editor. In that sense, the rule may be used to justify the use of big IDE software.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Orm Finnendahl hat gesagt: // Orm Finnendahl wrote:
does anybody know a way to send arbitrary length messages to arbitrary receivers? I would like to send OSC messages of variable length to pd, specifying the receiver in the first element of the message. It has to be completely dynamic as I want to create pd subpatchers dynamically, so OSCroute won't work.
It would be possible, if e.g. the send object allowed for a set message (or have a right inlet for setting the receiver), or if it was possible to use message boxes with Dollarsigns for arbitrary length messages.
Before patching pd's send I thought to better ask for a standard way to get this done.
There are various ways. If all you need is to add the "send" in front of the variable length list of data you want sendOSC to send, then you can use
whatever ... | [list prepend send] | [list trim] | [sendOSC]
If you actually want to send to a variable receiver, you can use some message-method trickery. I attached an example patch, however I don't like this approach in general.
A third solution would be to use a fixed send/receiver name and use [route] to route incoming messages according to their first element.
You can use the [list prepend]-[list trim] idiom to easily construct such messages.
Note that these solutions may require Pd 0.39 or better.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
A third solution would be to use a fixed send/receiver name and use [route] to route incoming messages according to their first element.
Forgot: For this approach a settable [route] is very useful. As Pd doesn't provide this (yet: There is a feature wish by me in the tracker), I made an abstraction which acts like a settable route. It's attache (and also part of [list]-abs in CVS.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
A third solution would be to use a fixed send/receiver name and use [route] to route incoming messages according to their first element.
You can use the [list prepend]-[list trim] idiom to easily construct such messages.
I attached an illustration of how I use this idea normally. Although I used [list] here, the basic approach works without it as well, I just used [list] because it's so convenient.
IMO this is almost fully equivalent to renaming sends and receives and should catch most cases where one might want to use these. The main advantage, or the advantage important to me is, that it reduces the number of globally visible receivers to basically one or two. I tend to avoid pollution of the receiver namespace whereever possible, but that may be a style or taste issue.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
B. Bogart -
carmen -
Frank Barknecht -
geiger -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Martin Peach -
Mathieu Bouchard -
Orm Finnendahl -
padawan12 -
Roman Haefeli -
Tim Blechmann