On Mon, 7 Jul 2008, Roman Haefeli wrote:
sorry, if i now seem to be nitpicking, but this is actually what i mean by 'core classes': the classes, that cover the initial focus of the library, in the case of gridflow the classes, that do deal with grids.
ok.
i don't think, that something hardcoded as [range 8 9 10] in [#camera]/[pd camera] justifies the use an extra external, if three [moses] objects cover exaxtly the same.
Look, [range] is in use in more abstractions than that, plus in more patches that you can see (unreleased stuff). [#camera] was just one example, and furthermore, [range] was just one example. There is also [route2], [listread], [listfind], and whatever else, that get used in abstractions, and that aren't as straightforward to replace by Miller's builtins.
i rather meant: is it really necessary to have the exact functionality of [range]? cannot the same be achieved by having some [moses]es here and there?
It's not the point.
different languages provide different ways to deal with issues.
And Pd doesn't provide enough when it comes to supporting abstractions in a way that makes them be able to use Pd in a way equivalent to how normal externals can use Pd, and at a price not significantly greater.
For example, [#in] and [#out] aren't in such great shape since they became abstractions, and they're significantly more complicated, because even the simplest dynamic patching is complicated.
At Pd Convention 2004, there was a nice moment during the papers sessions, where there was an apparent consensus that as many things as possible should be made as abstractions. I still think about that. I like the idea, and I've always liked the idea, and you can trace my appreciation of that idea back to the original design of GridFlow, but it's not always so feasible just by using Pd.
i might be wrong, but i haven't seen a case yet, where [range] would be the only option to solve a certain problem.
Originally [range] was only there so that when I convert jMax patches to Pd patches, I wouldn't have to do elaborate search-and-replaces. Although later on I could have decided to let it go and do things the Pd way, instead I came with the idea that [moses] was not enough and that if [sel] and [route] and such, take multiple number of arguments, [moses] should. In some patches I had to string 8 [moses] together.
Anyway, you seem to be on the defensive side... we don't absolutely need [range] so why bother? This is influenced by the fact that it is troublesome to make [range] in the first place, because at the same time it's not possible (or overly difficult) to make an abstraction out of it, and because it's troublesome to even carry portable C code around if it's not already in a very popular distro. If it were easy to make an abstraction, perhaps you wouldn't think like this. Or perhaps you would think like this about [range] anyway, but you wouldn't think like this about another example such as [route2].
but in this case i am more in favor of repeating [moses]es instead of introducing another class, that doesn't really cover new possibilities.
not much actually covers new possibilities. any abstraction could be just pasted in a patch so that you don't need the abstraction. It's all a matter of how much you're ok with doing that. It's more of a quantitative difference than qualitative.
in this particular case, i also prefer [moses], because it does not crash, while [range] crashes pd,
I don't have (nor remember) that bug.
I disavow any version of GridFlow prior to 0.9.2, and frankly, I also don't remember all of the bugs that might have been in 0.9.2 or 0.9.3. If you want to report bugs, do it relative to the last release, 0.9.4, or the SVN. (I uploaded it Friday, just didn't send an announcement yet).
from a developers perspective: why bother with making new code work, that introduces new problems and needs special attention, if pretty much the same could be achieved with a bit more effort in the user domain?
Exactly. So why bother improving Pd? It's hard, it introduces new problems, and needs special attention. If any possible improvement looks like it could be great, just break down this possible improvement into smaller, more incremental improvements, so that when you look at them individually, any of them looks like it's not worth doing. Looking at the big picture makes one worry, and we shouldn't worry, so let's not look at the big picture.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Originally [range] was only there so that when I convert jMax patches to Pd patches, I wouldn't have to do elaborate search-and-replaces. Although later on I could have decided to let it go and do things the Pd way, instead I came with the idea that [moses] was not enough and that if [sel] and [route] and such, take multiple number of arguments, [moses] should. In some patches I had to string 8 [moses] together.
btw such "range" is very feasible with only pd language and dynamic patching. see attached patch ;-)
On Mon, 7 Jul 2008, Claude Heiland-Allen wrote:
mescalinum@gmail.com wrote:
btw such "range" is very feasible with only pd language
dollarg ... couldn't create
Supposing you renamed [range] to [ff.range] or whatever else to avoid the name conflict, then you can replace [dollarg] with [args *] and ignore the right-outlet, and it will do the same except if you have parens or commas in the argument-list.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Claude Heiland-Allen wrote:
mescalinum@gmail.com wrote:
btw such "range" is very feasible with only pd language
dollarg ... couldn't create
it's from iemlib2.
my opinion is that such externals are so vital that should be internals, or part of the default pd distribution...
Best regards, Federico Ferri
On Tue, 2008-07-08 at 18:51 +0200, mescalinum@gmail.com wrote:
Claude Heiland-Allen wrote:
mescalinum@gmail.com wrote:
btw such "range" is very feasible with only pd language
dollarg ... couldn't create
it's from iemlib2.
my opinion is that such externals are so vital that should be internals, or part of the default pd distribution...
this is my opinion as well...
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Mon, 2008-07-07 at 23:36 +0200, mescalinum@gmail.com wrote:
Originally [range] was only there so that when I convert jMax patches to Pd patches, I wouldn't have to do elaborate search-and-replaces. Although later on I could have decided to let it go and do things the Pd way, instead I came with the idea that [moses] was not enough and that if [sel] and [route] and such, take multiple number of arguments, [moses] should. In some patches I had to string 8 [moses] together.
btw such "range" is very feasible with only pd language and dynamic patching. see attached patch ;-)
hey ciao federico
nice approach!
however, it has some flaws:
1. if you create a patch using your [range] abstraction, then connections from the outlets are cut next time you load the patch. this because you cannot create outlets dynamically early enough without something like an [initbang], that is executed even before [loadbang]
2. it _does_ require externals: [dollarg] is from iemlib
3. it is not exactly the same as matju's [range], since matjus version has an inlet per argument.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Tue, 8 Jul 2008, Roman Haefeli wrote:
Pd way, instead I came with the idea that [moses] was not enough and that if [sel] and [route] and such, take multiple number of arguments, [moses] should. In some patches I had to string 8 [moses] together.
btw such "range" is very feasible with only pd language and dynamic patching. see attached patch ;-)
- if you create a patch using your [range] abstraction, then
connections from the outlets are cut next time you load the patch. this because you cannot create outlets dynamically early enough without something like an [initbang], that is executed even before [loadbang]
Actually, I just found a hack. Edit your .pd file with a text editor in this way:
1. replace "loadbang;" by "r $0-initbang;"
2. add a line at the very end that says just "$0-initbang bang;", no backslash, no "#X obj", no object position.
This works in all versions of Pd. If you don't understand how this works, it's normal. Furthermore, to edit this patch, -noloadbang does not work anymore, so you have to undo step 2 before any edit in pd, and redo it after any edit in pd.
So, yes, it can be done in Pd ! But my main point was that it's usually much less trouble to write the damn thing in C.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Mathieu Bouchard wrote:
- if you create a patch using your [range] abstraction, then
connections from the outlets are cut next time you load the patch. this because you cannot create outlets dynamically early enough without something like an [initbang], that is executed even before [loadbang]
Actually, I just found a hack. Edit your .pd file with a text editor in this way:
replace "loadbang;" by "r $0-initbang;"
add a line at the very end that says just "$0-initbang bang;", no backslash, no "#X obj", no object position.
This works in all versions of Pd. If you don't understand how this works, it's normal. Furthermore, to edit this patch, -noloadbang does not work anymore, so you have to undo step 2 before any edit in pd, and redo it after any edit in pd.
hey that is a hack! ;-) (a nice one!)
but has also an additional drawback: you have to add '$0-initbang bang;' each time you edit the patch in pd, cause pd discards everything it doesn't know about. this is a nice point for a feature request of an internal [initbang].
indeed, you are right... dynamic patching in Pd is still troublesome.
anyway it doesn't mean that things are impossible... they just require you much thinking.
my example (of range.pd) was just a proof of concept.
and also, it's true: if you know how to code externals (example: C, or even Tcl (tclpd) or Python (pyext)) you probably do the same thing by programming rather than by patching it, especially if it's not properly straightforward.
Best regards, Federico Ferri
On Tue, 8 Jul 2008, mescalinum@gmail.com wrote:
but has also an additional drawback: you have to add '$0-initbang bang;' each time you edit the patch in pd, cause pd discards everything it doesn't know about.
This can be solved easily by doing something like this:
t_class *c; void at_init_new (t_symbol *, int argc, t_atom *argv) { t_binbuf *b = binbuf_new(); binbuf_add(b,argc,argv); binbuf_eval(b,0,0,0); binbuf_free(b); return pd_new(c); /* bogus, just so that it gets saved */ } c = class_new(gensym("at_init"),at_init_new,0,sizeof(t_object),0,0);
That way, you have a version of the same thing that will be saved by the regular canvas-saving mechanism and will be otherwise the same. Thus this line:
$0-initbang bang;
Would look like this instead:
#X obj 242 666 $0-initbang bang;
But the problem with that one is that this object has to occur last in the list of objects, but anyway, as I said, the patch is already sensitive to its own object-numbering, so this kind of external doesn't really improve anything. (Your patch is also sensitive to connection-ordering, but this is nothing that a few [t a a] can't fix.)
this is a nice point for a feature request of an internal [initbang].
But nice points don't make features happen.
anyway it doesn't mean that things are impossible... they just require you much thinking.
Well, my main point was not about impossibility, it was about some Pd abstractions being so troublesome that it would just be easier to write them in C instead.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Mon, 7 Jul 2008, mescalinum@gmail.com wrote:
btw such "range" is very feasible with only pd language and dynamic patching.
It can't be used in practice. Try putting it in a patch, save the patch, reload the patch. All connections from the outlets of this [range] will fail. This is because it uses [loadbang] instead of [initbang], and because [initbang] does not exist. This proves one of my points.
Then this patch can't be edited with plain pd because this changes the object numbering, which is not written anywhere in a patch, and changing the object numbering breaks the dynamic patching. This is the sort of problem that was solved with the introduction of assembly language as a replacement to machine language... and frankly I'd rather program in C than in either of those. This proves another one of my points. But on top of that, you can't edit that abstraction and resave it while pd is not running in -noloadbang mode.
Thanks for providing the example that illustrates the two main problems that I see with what is about the best that one can do with normal pd (even with externals).
The third issue is that your version lacks the dynamic inlets, but that's a detail, and I know you can do it, and it's not worth fixing it until your abstraction can be used in practice.
The workaround for the lack of [initbang] is to set an arbitrary limit on number of dynamic inlets/outlets, have them created in advance, and delete the extraneous inlets/outlets at [loadbang] time so that the object looks nice. Sort of underwhelming, but it would work for most purposes.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Mathieu Bouchard wrote:
On Mon, 7 Jul 2008, mescalinum@gmail.com wrote:
btw such "range" is very feasible with only pd language and dynamic patching.
It can't be used in practice. Try putting it in a patch, save the patch, reload the patch. All connections from the outlets of this [range] will fail. This is because it uses [loadbang] instead of [initbang], and because [initbang] does not exist. This proves one of my points.
Then this patch can't be edited with plain pd because this changes the object numbering, which is not written anywhere in a patch, and changing the object numbering breaks the dynamic patching. This is the sort of problem that was solved with the introduction of assembly language as a replacement to machine language... and frankly I'd rather program in C than in either of those. This proves another one of my points. But on top of that, you can't edit that abstraction and resave it while pd is not running in -noloadbang mode.
Thanks for providing the example that illustrates the two main problems that I see with what is about the best that one can do with normal pd (even with externals).
The third issue is that your version lacks the dynamic inlets, but that's a detail, and I know you can do it, and it's not worth fixing it until your abstraction can be used in practice.
The workaround for the lack of [initbang] is to set an arbitrary limit on number of dynamic inlets/outlets, have them created in advance, and delete the extraneous inlets/outlets at [loadbang] time so that the object looks nice. Sort of underwhelming, but it would work for most purposes.
thanks for your argument. I just filed a feature request for pd [1] and I hope someone finds the time to implement it. I could do it perhaps, but I'm really busy with school right now.
Best regards, Federico Ferri
1: http://sourceforge.net/tracker/index.php?func=detail&aid=2013658&gro...
mescalinum@gmail.com wrote:
Mathieu Bouchard wrote: thanks for your argument. I just filed a feature request for pd [1] and I hope someone finds the time to implement it.
hmm, how about my implementation of [initbang] from october 2006? as posted in: http://sourceforge.net/tracker/index.php?func=detail&aid=1544041&gro...
fmgasr., IOhannes
On Jul 9, 2008, at 4:03 AM, IOhannes m zmoelnig wrote:
mescalinum@gmail.com wrote:
Mathieu Bouchard wrote: thanks for your argument. I just filed a feature request for pd [1] and I hope someone finds the time to implement it.
hmm, how about my implementation of [initbang] from october 2006? as posted in: http://sourceforge.net/tracker/index.php? func=detail&aid=1544041&group_id=55736&atid=478072
FYI: it is also included in Pd-extended.
.hc
fmgasr., IOhannes
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
And Pd doesn't provide enough when it comes to supporting abstractions in a way that makes them be able to use Pd in a way equivalent to how normal externals can use Pd, and at a price not significantly greater.
For example, [#in] and [#out] aren't in such great shape since they became abstractions, and they're significantly more complicated, because even the simplest dynamic patching is complicated.
At Pd Convention 2004, there was a nice moment during the papers sessions, where there was an apparent consensus that as many things as possible should be made as abstractions. I still think about that. I like the idea, and I've always liked the idea, and you can trace my appreciation of that idea back to the original design of GridFlow, but it's not always so feasible just by using Pd.
I think, Pd could benefit a lot by providing a default scripting language to write operations like [range] which are tediuos to do as an abstraction. Altough I'm not a fan of Tcl (and would prefer Lua), Tcl would be a natural choice as it's available anyway. Ideally the scripts would be saved within the patch, e.g. inside message boxes. Oh wait, that's toxy! Hm, ... but toxy has a horrible syntax, which I could never get around. But the general approach of it is a fantastic idea.
The advantages of a scripted Pd classes are: For certain tasks, especially those involving lots of repetition, patching is too much work. And as pd-extended shows, if you pack each and every external and abstraction into the pd-distribution, you either have to deal with ugly long names or live with namespace pollution.
Btw.: That's why today I tend to avoid installing lots of externals and rather copy them to a project's folder when needed. Apart from extensions that provide special functionality like Gem, msd, OSC or iemfilters, I don't use "convenience collections" like maxlib anymore - expect my own of course. Joao would probably call me a hardcore user. ;)
Ciao
On Wed, 9 Jul 2008, Frank Barknecht wrote:
I think, Pd could benefit a lot by providing a default scripting language to write operations like [range] which are tediuos to do as an abstraction.
At this point I don't mind having it written in C++, really. The code is only 25 lines long and I can see it getting shorter as I introduce more shortcuts.
Altough I'm not a fan of Tcl (and would prefer Lua), Tcl would be a natural choice as it's available anyway.
That's what I thought, but then I realised that I was less of a fan of Tcl than I previously thought. In the end I decided to stick with C++ and Pd (abstractions). I decided that this would be a good occasion to make it easier to make abstractions.
I don't know Lua, but even though reading about it doesn't make me think that the syntax is cool like Tcl's is, I can't really stand "everything is a string" in Tcl. I don't mind the lack of a standard object model in Lua, as Tcl also lacks one, so I wrote myself one in a record low number of lines.
Ideally the scripts would be saved within the patch, e.g. inside message boxes.
That's not quite ideal, because it makes it hard to load once and use many times. It's already a problem with Pd abstractions... the whole patch structure is being reloaded repeatedly, and even reparsed. If you use an abstraction 100 times, it will have 100 copies of the connections and will have parsed the abstraction 100 times.
Oh wait, that's toxy! Hm, ... but toxy has a horrible syntax, which I could never get around.
That's because Pd has a horrible sin tax. It can be bypassed by making a GUI object specific to that, that will allow to write and paste source code directly into a box, without being hindered by Pd's syntax.
But the general approach of it is a fantastic idea.
I agree, as long as there is also the alternative of not writing source code in patches.
The advantages of a scripted Pd classes are: For certain tasks, especially those involving lots of repetition, patching is too much work.
Many patterns of lots of repetition can be covered using some classes that would work like [nqpoly] and [polypoly] but better.
And as pd-extended shows, if you pack each and every external and abstraction into the pd-distribution, you either have to deal with ugly long names or live with namespace pollution.
This is a separate issue that is mostly unrelated to scripting.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Hi,
Frank Barknecht a écrit :
I think, Pd could benefit a lot by providing a default scripting language to write operations like [range] which are tediuos to do as an abstraction. Altough I'm not a fan of Tcl (and would prefer Lua), Tcl would be a natural choice as it's available anyway. Ideally the scripts would be saved within the patch, e.g. inside message boxes. Oh wait, that's toxy! Hm, ... but toxy has a horrible syntax, which I could never get around. But the general approach of it is a fantastic idea.
Having a default scripting language is certainly the best thing that could happen to puredata, I think. We wouldn't have to deal anymore with externals and get headaches for manipulating strings, and (maybe) for custumizing our own widgets without having to touch pd.tk or compiling. The problem of toxy horrible synthax doesn't come from toxy but like almost everyone know, from puredata's 'dropped keycodes', so it would be the same with any other language wrapper that allow to store the code into the patch (just try to launch a sed command line with [shell] to have an idea...)
à plus
The advantages of a scripted Pd classes are: For certain tasks, especially those involving lots of repetition, patching is too much work. And as pd-extended shows, if you pack each and every external and abstraction into the pd-distribution, you either have to deal with ugly long names or live with namespace pollution.
Btw.: That's why today I tend to avoid installing lots of externals and rather copy them to a project's folder when needed. Apart from extensions that provide special functionality like Gem, msd, OSC or iemfilters, I don't use "convenience collections" like maxlib anymore
- expect my own of course. Joao would probably call me a hardcore
user. ;)
Ciao
On Fri, Jul 11, 2008 at 08:19:09AM +0200, patrice colet wrote:
Hi,
Frank Barknecht a écrit :
I think, Pd could benefit a lot by providing a default scripting language to write operations like [range] which are tediuos to do as an abstraction. Altough I'm not a fan of Tcl (and would prefer Lua), Tcl would be a natural choice as it's available anyway. Ideally the scripts would be saved within the patch, e.g. inside message boxes. Oh wait, that's toxy! Hm, ... but toxy has a horrible syntax, which I could never get around. But the general approach of it is a fantastic idea.
Having a default scripting language is certainly the best thing that could happen to puredata, I think.
Agreed. Would love to hear what Miller thinks, or if there is even a remote possibility a scripting language will ever make it into Miller-Vanilla.
Chris.
------------------- http://mccormick.cx
Frank Barknecht wrote:
I think, Pd could benefit a lot by providing a default scripting language to write operations like [range] which are tediuos to do as an abstraction. Altough I'm not a fan of Tcl (and would prefer Lua), Tcl would be a natural choice as it's available anyway.
But Tcl is awfully slow. In fact, it's one of the slowest scripting languages there is. Lua has a very low footprint which makes it usable even in embedded environments, and it's a lot faster than Tcl (especially the JIT-compiled version, but AFAICT this only works on x86 right now). The only advantage that Tcl has is, as you point out, that Pd already uses it anyway.
Since a few months I've been working on my own JIT-compiled language "Pure", Q's successor, which is not much slower than LuaJIT, allows you to call C functions directly, and runs on anything that LLVM [http://llvm.org/] supports, including Linux/OSX/Windows and x86/-64/powerpc. A port of Q's Pd external, which will make Pure callable from Pd, is one of the next items on my TODO list.
Now I know how popular functional programming languages are with programmers raised on a diet of C, Python and Java ;-), but the fact is that FPLs are a nice match for Pd (which is a kind of functional programming language itself) and typically the scripts are much more concise and expressive than anything you can write in more traditional languages.
Ideally the scripts would be saved within the patch, e.g. inside message boxes.
Ideally we'd have this sort of integration for any scripting language supported by an external, so that the scripting engine could query Pd for the script name or text to use for a given patch and initialize itself accordingly before any objects are created. Currently you either have to specify the script as an object creation argument or hardwire it into the scripting language external. Both sucks.
If Pd provided some infrastructure there (maybe [declare] could already be used for that purpose?), scripting would become as easy as pie, and we won't have to battle over which scripting language is best, because there are already quite a few to choose from.
Cheers, Albert
On Fri, 11 Jul 2008, Albert Graef wrote:
The only advantage that Tcl has is, as you point out, that Pd already uses it anyway.
Another advantage of Tcl is that the syntax is like that of Pd: space-separated elements, not much quoting necessary. In addition, elements missing from Pd and characters missing from Pd together suggest making it more like Tcl, because those missing characters correspond to the special characters in Tcl that are implement the features most missing from Pd.
Now I know how popular functional programming languages are with programmers raised on a diet of C, Python and Java ;-), but the fact is that FPLs are a nice match for Pd (which is a kind of functional programming language itself)
You got to be kidding. Perhaps you are using another definition of functional language. The Pd/MAX message system (non-signal) is most likely the most stateful (non-functional) dataflow language around. By functional it is usually meant something fairly stateless or in which you can largely avoid statelessness whenever it makes sense. Academic dataflow languages (in computer science depts I mean) are quite stateless, whereas Pd/MAX lie at the opposite end of the spectrum.
and typically the scripts are much more concise and expressive than anything you can write in more traditional languages.
Well, it depends a lot. Functional problems will have short functional solutions, and imperative problems will have short imperative solutions.
If Pd provided some infrastructure there (maybe [declare] could already be used for that purpose?), scripting would become as easy as pie, and we won't have to battle over which scripting language is best, because there are already quite a few to choose from.
You can't wait for Pd to support anything in particular.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Mathieu Bouchard wrote:
You got to be kidding. Perhaps you are using another definition of functional language. The Pd/MAX message system (non-signal) is most likely the most stateful (non-functional) dataflow language around.
So what? Most FPLs deal with state just fine. Even purely functional languages do, through special abstractions like streams or monads. At the end of the day, Pd objects are just boxes taking inputs and producing outputs, which can be programmed in FPLs quite easily. And FPLs provide the tools to express such transformations in a convenient way, such as pattern-matching (a.k.a. symbolic rewriting) and higher order functions.
But my point was certainly *not* to propose an FPL as Pd's default scripting language. My point is that it would be nice to have just a little infrastructure to better support language interfaces in general, no matter whether Pd will provide some default scripting interface in the future or not.
Well, it depends a lot. Functional problems will have short functional solutions, and imperative problems will have short imperative solutions.
Well, I wouldn't talk about "functional" or "imperative problems" here, but it's certainly true that some stuff tends to be easier in one language and other stuff in another one. However, that just illustrates my point that it's better to have an interface that accomodates different scripting languages, instead of singling out Tcl as the be all and end all of it.
You can't wait for Pd to support anything in particular.
I won't. But would it really hurt if [declare] supported, say, a -script option so that a language external could inspect that attribute of a patch and use it as the name of a script to be loaded? That just needs one routine in the plugin API which allows externals to read the attributes of a patch (which might be there already, I haven't checked lately).
Cheers, Albert
On Sat, 12 Jul 2008, Albert Graef wrote:
So what? Most FPLs deal with state just fine. Even purely functional languages do, through special abstractions like streams or monads.
Do talk to Claude about whether it's worth the effort.
Pd objects are just boxes taking inputs and producing outputs
That's not the Pd I know.
My point is that it would be nice to have just a little infrastructure to better support language interfaces in general,
I always agreed with that.
Well, it depends a lot. Functional problems will have short functional solutions, and imperative problems will have short imperative solutions.
Well, I wouldn't talk about "functional" or "imperative problems" here, but it's certainly true that some stuff tends to be easier in one language and other stuff in another one.
This is exactly what I mean.
However, that just illustrates my point that it's better to have an interface that accomodates different scripting languages, instead of singling out Tcl as the be all and end all of it.
Agreeing on a most interesting scripting language, and agreeing on new support for scripting (and other) languages, is two different things.
You can't wait for Pd to support anything in particular.
I won't. But would it really hurt if [declare] supported, say, a -script option so that a language external could inspect that attribute of a patch and use it as the name of a script to be loaded?
This is redundant... -lib already does it, together with loader_t. (yes, it's called loader_t, as opposed to all other Pd C types).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
Mathieu Bouchard wrote:
Do talk to Claude about whether it's worth the effort.
Well, Claude's external interfaces to Haskell, which of course poses problems because Haskell confines side-effects to monads and is statically typed. These are non-issues in Q and Pure which allow side-effects without any ado and are dynamically typed, so interfacing to Pd is much easier and works very well.
This is redundant... -lib already does it, together with loader_t. (yes, it's called loader_t, as opposed to all other Pd C types).
Right, now I even remember reading about this, probably in Claude's pdlua sources. :) Thanks, I will try this in my Pure external.
Albert
On Jul 12, 2008, at 9:35 AM, Albert Graef wrote:
Mathieu Bouchard wrote:
You got to be kidding. Perhaps you are using another definition of functional language. The Pd/MAX message system (non-signal) is most likely the most stateful (non-functional) dataflow language around.
So what? Most FPLs deal with state just fine. Even purely functional languages do, through special abstractions like streams or monads. At the end of the day, Pd objects are just boxes taking inputs and producing outputs, which can be programmed in FPLs quite easily. And FPLs provide the tools to express such transformations in a convenient way, such as pattern-matching (a.k.a. symbolic rewriting) and higher order functions.
But my point was certainly *not* to propose an FPL as Pd's default scripting language. My point is that it would be nice to have just a little infrastructure to better support language interfaces in general, no matter whether Pd will provide some default scripting interface in the future or not.
Well, it depends a lot. Functional problems will have short functional solutions, and imperative problems will have short imperative solutions.
Well, I wouldn't talk about "functional" or "imperative problems" here, but it's certainly true that some stuff tends to be easier in one language and other stuff in another one. However, that just illustrates my point that it's better to have an interface that accomodates different scripting languages, instead of singling out Tcl as the be all and end all of it.
You can't wait for Pd to support anything in particular.
I won't. But would it really hurt if [declare] supported, say, a - script option so that a language external could inspect that attribute of a patch and use it as the name of a script to be loaded? That just needs one routine in the plugin API which allows externals to read the attributes of a patch (which might be there already, I haven't checked lately).
Implement it, and we'll see if it hurts. :) Sounds worth trying.
.hc
Cheers, Albert
-- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef@t-online.de, ag@muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
Hans-Christoph Steiner wrote:
Implement it, and we'll see if it hurts. :) Sounds worth trying.
See my reply to Mathieu's other message; looks like the new loader infrastructure already does everything I want. :)
Albert
-
Albert Graef -
Chris McCormick -
Claude Heiland-Allen -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Mathieu Bouchard -
mescalinum＠gmail.com -
patrice colet -
Roman Haefeli