It would be awesome don't you think ?!!
Since Pd already is, imagine a little one you can carry on your pocket. I have lots of sound-music applications on it (elektroplankton, korg ds-10, nitrotracker, lots of home brew).. they are great, but we all know they can't do what pd can. Imagine a little vanilla, you just mess with the objects on the touchscreen, man .. who is interested?
To start there is this app from chris Mccormix that allows you to control pd patches from your ds: http://mccormick.cx/projects/KnobsAndSlidersDS/ I don't know if it's maintained though.
n
Le 10/08/09 14:48, Gabriel Vinazza a écrit :
It would be awesome don't you think ?!!
Since Pd already is, imagine a little one you can carry on your pocket. I have lots of sound-music applications on it (elektroplankton, korg ds-10, nitrotracker, lots of home brew).. they are great, but we all know they can't do what pd can. Imagine a little vanilla, you just mess with the objects on the touchscreen, man .. who is interested?
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thanks Nico, I already have it. I would like a pd application, not a remote controller. This way I would always have to carry with my notebook. I'm thinking of creating patches on the DS while I'm on the bus or wherever!
Do you know if it's possible or if there's a similar application?
On Mon, Aug 10, 2009 at 10:00 AM, Nicolas Montgermontnicolas_montgermont@yahoo.fr wrote:
To start there is this app from chris Mccormix that allows you to control pd patches from your ds: http://mccormick.cx/projects/KnobsAndSlidersDS/ I don't know if it's maintained though.
n
Le 10/08/09 14:48, Gabriel Vinazza a écrit :
It would be awesome don't you think ?!!
Since Pd already is, imagine a little one you can carry on your pocket. I have lots of sound-music applications on it (elektroplankton, korg ds-10, nitrotracker, lots of home brew).. they are great, but we all know they can't do what pd can. Imagine a little vanilla, you just mess with the objects on the touchscreen, man .. who is interested?
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, Aug 10, 2009 at 03:00:48PM +0200, Nicolas Montgermont wrote:
To start there is this app from chris Mccormix that allows you to
control pd patches from your ds: http://mccormick.cx/projects/KnobsAndSlidersDS/ I don't know if it's maintained though.
It is not very maintained! That said, I don't know about any bugs, and I don't really have any features I want to add to it.
I had a couple of shots at porting PDa to NDS but kind of always got blocked and lost interest. There are two choices:
- Port PDa to DSLinux.
- Port PDa straight to code running out of a rom, like a homebrew game does.
DSLinux probably incurs too much overhead to run Pd well. It's already quite slow and I think sticking PDa in there would really make it sad in the CPU department. The bare-to-the-metal approach of running it as a rom is more difficult though because Pd and PDa assume a bunch of OS facilities are available (dlopen etc.) which they aren't when you make NDS roms.
Porting tcl/tk is probably out of the question, unless there is some embedded port of tcl/tk and even then I think you'd be really pushing it. So I think you'd have to roll your own GUI system like I did for Gp2xPd.
Best,
Chris.
Le 10/08/09 14:48, Gabriel Vinazza a écrit :
It would be awesome don't you think ?!!
Since Pd already is, imagine a little one you can carry on your pocket. I have lots of sound-music applications on it (elektroplankton, korg ds-10, nitrotracker, lots of home brew).. they are great, but we all know they can't do what pd can. Imagine a little vanilla, you just mess with the objects on the touchscreen, man .. who is interested?
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
I think there is a problem in section 2.3.2 of the Pd Manual:
"It is indeterminate which of "B" or "C" is done first; this depends on what order you made the connections in (in Max, it's automatically sorted right to left)."
First of all, the part before the semicolon contradicts the part that follows the semicolon.
Second of all, the next paragraph talks about infinite loops; [trigger] isn't addressed until the following section, momentarily making it seem as if "the order you made the connections in" is an feature of the language that is somehow analogous to Max's right-to-left sorting.
This may seem nitpicky, but I think the analogous Pd feature in this case is Pd's reliance on [trigger] as the main way to specify execution order. I think [trigger] should be mentioned before the the quoted material above (or at least immediately following) so that the comparison to Max is as follows:
Max: When multiple connections are made from an object, they are executed in right-to-left order. This makes it easy to know the execution order simply by looking at a patch, but can make it tricky to reorganize the patch (unless [trigger] is used explicitly).
Pd: When the execution order needs to be specified, the user explicitly
uses a [trigger] object. This means you can look at a patch and tell the execution order, _and_ (aside from [inlet] and [outlet]) objects can be reorganized without the risk of changing the execution order.
Finally, if there are multiple connections from an object and [trigger]
is not used, it can be assumed that either execution order shouldn't
matter in that instance, or that the person making the patch has forgotten
to specify it (in which case it is an error and [trigger] should be
utilized).
The fact that Pd executes in the order the connections were made only makes sense in light of the explicit use of [trigger]. Even if Pd rolled some virtual dice to determine execution order when multiple connections are coming from a single object, most of our patches would work the same because we all use [trigger] explicitly in Pd, right?
I know the Pd manual doesn't make assumption about how someone _should_ use Pd, but I think this is an exception, because anyone who is relying on the order they make connections is going to have a hard time getting anywhere. Plus, it seems like an unusual number of people have said (or written) that Pd "relies" on the order in which you make connections for the execution order, which isn't true.
Does this make sense?
-Jonathan
On Mon, 10 Aug 2009, Jonathan Wilkes wrote:
Second of all, the next paragraph talks about infinite loops; [trigger] isn't addressed until the following section, momentarily making it seem as if "the order you made the connections in" is an feature of the language that is somehow analogous to Max's right-to-left sorting.
Furthermore, I'd say it should be introduced as [t a a], [t f b], etc., right away. It shouldn't give the impression that properly ordering things in pd is something cumbersome that eats away half the width of the patch (or all of it).
The fact that Pd executes in the order the connections were made only makes sense in light of the explicit use of [trigger]. Even if Pd rolled some virtual dice to determine execution order when multiple connections are coming from a single object, most of our patches would work the same because we all use [trigger] explicitly in Pd, right?
It's not just that, it's that sometimes, the order just doesn't matter at all.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Yeah, good point. The "connection order" statement should really be a
footnote. [trigger] should really be introduced before talking about
the connection order.
.hc
On Aug 10, 2009, at 4:44 PM, Jonathan Wilkes wrote:
I think there is a problem in section 2.3.2 of the Pd Manual:
"It is indeterminate which of "B" or "C" is done first; this depends
on what order you made the connections in (in Max, it's automatically
sorted right to left)."First of all, the part before the semicolon contradicts the part that follows the semicolon.
Second of all, the next paragraph talks about infinite loops;
[trigger] isn't addressed until the following section, momentarily making it
seem as if "the order you made the connections in" is an feature of the language that is somehow analogous to Max's right-to-left sorting.This may seem nitpicky, but I think the analogous Pd feature in this case is Pd's reliance on [trigger] as the main way to specify execution order. I think [trigger] should be mentioned before the the quoted material above (or at least immediately
following) so that the comparison to Max is as follows:Max: When multiple connections are made from an object, they are
executed in right-to-left order. This makes it easy to know the execution
order simply by looking at a patch, but can make it tricky to reorganize the patch (unless [trigger] is used explicitly).Pd: When the execution order needs to be specified, the user
explicitly uses a [trigger] object. This means you can look at a patch and tell
the execution order, _and_ (aside from [inlet] and [outlet]) objects
can be reorganized without the risk of changing the execution order. Finally, if there are multiple connections from an object and
[trigger] is not used, it can be assumed that either execution order shouldn't matter in that instance, or that the person making the patch has
forgotten to specify it (in which case it is an error and [trigger] should be utilized).The fact that Pd executes in the order the connections were made only makes sense in light of the explicit use of [trigger]. Even if Pd
rolled some virtual dice to determine execution order when multiple connections are coming from a single object, most of our patches would work the same because we all use [trigger] explicitly in Pd, right?I know the Pd manual doesn't make assumption about how someone
_should_ use Pd, but I think this is an exception, because anyone who is
relying on the order they make connections is going to have a hard time
getting anywhere. Plus, it seems like an unusual number of people have said (or written) that Pd "relies" on the order in which you make
connections for the execution order, which isn't true.Does this make sense?
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
On Tue, 11 Aug 2009, Hans-Christoph Steiner wrote:
Yeah, good point. The "connection order" statement should really be a footnote. [trigger] should really be introduced before talking about the connection order.
I don't believe that any of those things should be introduced before or after the other, nor that any of those things deserves to be but a footnote in the other's text, or anything else like that.
There is a reason for the existence of [trigger], and it's not "for triggering things" in any traditional meaning of the word in a way that is contrastive with what any object not named [trigger] does... the meaning of the word "triggering" in a pd context is conditioned by the existence of the class-name [trigger] and not the other way around.
[trigger] has been created especially for ordering things in a way that a fanout can't, that is, visually, explicitly, and unambiguously; thus [trigger] and the very need for ordering go hand in hand.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Le mardi 11 août 2009 à 13:24 -0400, Mathieu Bouchard a écrit :
On Tue, 11 Aug 2009, Hans-Christoph Steiner wrote:
Yeah, good point. The "connection order" statement should really be a footnote. [trigger] should really be introduced before talking about the connection order.
I don't believe that any of those things should be introduced before or after the other, nor that any of those things deserves to be but a footnote in the other's text, or anything else like that.
There is a reason for the existence of [trigger], and it's not "for triggering things" in any traditional meaning of the word in a way that is contrastive with what any object not named [trigger] does... the meaning of the word "triggering" in a pd context is conditioned by the existence of the class-name [trigger] and not the other way around.
[trigger] has been created especially for ordering things in a way that a fanout can't, that is, visually, explicitly, and unambiguously; thus [trigger] and the very need for ordering go hand in hand.
Or, sometimes, it can be used to connect an outlet of an object to its cold inlet. For example for a counter : [1( | [-1( |/ [+ ]x[t f] | [print]
++
Jack
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Tue, 11 Aug 2009, Jack wrote:
Or, sometimes, it can be used to connect an outlet of an object to its cold inlet. For example for a counter :
Yeah. But I was talking about what it was created for. It's also useful for what you say, but there are other ways that are equally natural, such as a [s]/[r] pair... I used to write a plain [f] there. [f] takes a tiny bit more RAM and is a tiny bit faster, though I suppose it's usually an unimportant difference. This is not the reason I picked [f] over [t f], it's just that [f] is the first thing that came to my mind when I realised that I had to circumvent Pd's "foolproof" manners.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
-
Chris McCormick -
Gabriel Vinazza -
Hans-Christoph Steiner -
Jack -
Jonathan Wilkes -
Mathieu Bouchard -
Nicolas Montgermont