Hi there... I have a problem with reading data from my avr uC in puredata on win2k. I am getting the ascii values of the numbers I am sending but not the actual numbers. What is the problem? What is the comport object expecting?
I would rather not convert these values in pd, but I can't try this out because I can't find the external ascii2any as a windows dll.. does anyone have it?
thank you for any help.
ian c.
hi ian,
Am Donnerstag 17 November 2005 20:49 schrieb ian campbell:
Hi there... I have a problem with reading data from my avr uC in puredata on win2k. I am getting the ascii values of the numbers I am sending but not the actual numbers.
just substract the offset of the ascii value to the number value, which is 48.
ascii 48 = "0" ascii 49 = "1" etc....
other way round if you receive bytes that represent a number, but want the ascii value .....
What is the problem? What is the comport object expecting?
I would rather not convert these values in pd, but I can't try this out because I can't find the external ascii2any as a windows dll.. does anyone have it?
thank you for any help.
ian c.
greetings,
chris
ian campbell wrote:
Hi there... I have a problem with reading data from my avr uC in puredata on win2k. I am getting the ascii values of the numbers I am sending but not the actual numbers. What is the problem? What is the comport object expecting?
The comport object puts out floats, so you probably _are_ sending it the ascii values of the numbers you want. If you can program your avr, send raw data instead.
Martin
I would rather not convert these values in pd, but I can't try this out because I can't find the external ascii2any as a windows dll.. does anyone have it? thank you for any help.
ian c.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You don't need any C objects aka externals to do this. Here's a Pd patch that does the conversion using only core objects:
float/int (inlet) --> ASCII character (outlet)
.hc
On Nov 17, 2005, at 2:49 PM, ian campbell wrote:
Hi there... I have a problem with reading data from my avr uC in
puredata on win2k. I am getting the ascii values of the numbers I am sending but not the
actual numbers. What is the problem? What is the comport object expecting?I would rather not convert these values in pd, but I can't try this
out because I can't find the external ascii2any as a windows dll.. does anyone have
it? thank you for any help.ian c.
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
Le 17 Novembre 2005 13:32, Hans-Christoph Steiner a écrit :
You don't need any C objects aka externals to do this. Here's a Pd patch that does the conversion using only core objects:
float/int (inlet) --> ASCII character (outlet)
Good good, but then, how to combine those single characters into useful messages and lists for PD? That's not an easy task, and that's why I programmed the ascii2any and any2ascii externals. I hope to update them to the latest Flext, and maybe compile it for Windows... -- Marc
On Nov 17, 2005, at 1:47 PM, Marc Lavallée wrote:
Le 17 Novembre 2005 13:32, Hans-Christoph Steiner a écrit :
You don't need any C objects aka externals to do this. Here's a Pd patch that does the conversion using only core objects:
float/int (inlet) --> ASCII character (outlet)
Good good, but then, how to combine those single characters into useful messages and lists for PD? That's not an easy task, and that's why I programmed the ascii2any and any2ascii externals. I hope to update
them to the latest Flext, and maybe compile it for Windows...
You could change [makefilename]s together, or something with the new
[list] object would probably be possible. But the ascii2any are handy,
get them in the extended builds!
.hc
Marc
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
There is no way to peace, peace is the way.
-A.J. Muste
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Nov 17, 2005, at 1:47 PM, Marc Lavallée wrote:
Good good, but then, how to combine those single characters into useful messages and lists for PD? That's not an easy task, and that's why I programmed the ascii2any and any2ascii externals. I hope to update
them to the latest Flext, and maybe compile it for Windows...You could change [makefilename]s together, or something with the new
[list] object would probably be possible.
At first I thought: No way, you'd need at least [list2symbol] for that, which is impossible to build with just internal objects. Then I said to myself: Hm, maybe it's not impossible? Then I said down and it wasn't even that hard to do a [list2symbol] clone using just builtins: list-2s.pd is attached. Oops, there goes another external previously used in RRADical ... ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Nov 18, 2005, at 6:14 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Nov 17, 2005, at 1:47 PM, Marc Lavallée wrote:
Good good, but then, how to combine those single characters into
useful messages and lists for PD? That's not an easy task, and that's why I programmed the ascii2any and any2ascii externals. I hope to update them to the latest Flext, and maybe compile it for Windows...You could change [makefilename]s together, or something with the new [list] object would probably be possible.
At first I thought: No way, you'd need at least [list2symbol] for that, which is impossible to build with just internal objects. Then I said to myself: Hm, maybe it's not impossible? Then I said down and it wasn't even that hard to do a [list2symbol] clone using just builtins: list-2s.pd is attached. Oops, there goes another external previously used in RRADical ... ;)
That's great! I've started a project I call "PurePd". Whenever I get
inspired, I write a Pd patch that is a clone of a useful external. I
just added it to abstractions/purepd and the build system. It would be
great if you could contribute this patch as [list2symbol] and anything
else that you can think of. I have a Max-style [counter], [speedlim],
and even a [metro] in the works.
I have also started writing objects in Pd that make writing objects in
Pd much easier. Things like [float_argument] and [symbol_argument]
which handle receiving arguments, and can distinguish between when the
object is instantiated with an argument, and when it is not. Other
ideas I have for patches in this genre are a debug objects that can be
controlled locally or by a global send/receive. Also, I have been
sketching out print_error and print_version objects.
I need a new name for this second project now, since it makes sense to
keep it distinct from PurePd. "libtools" comes to mind....
.hc
http://at.or.at/hans/
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Nov 18, 2005, at 6:14 PM, Frank Barknecht wrote:
At first I thought: No way, you'd need at least [list2symbol] for that, which is impossible to build with just internal objects. Then I said to myself: Hm, maybe it's not impossible? Then I said down and it wasn't even that hard to do a [list2symbol] clone using just builtins: list-2s.pd is attached. Oops, there goes another external previously used in RRADical ... ;)
That's great! I've started a project I call "PurePd". Whenever I get
inspired, I write a Pd patch that is a clone of a useful external. I
just added it to abstractions/purepd and the build system. It would be
great if you could contribute this patch as [list2symbol] and anything
else that you can think of. I have a Max-style [counter], [speedlim],
and even a [metro] in the works.
I already added it to the [list]-abs renamed to "list-l2s", because maybe there will be a "list-s2l" later, too. Although I currently think: No way to do this without externals, but who knows ... ;)
I think, in this case it feel natural to put it in [list]-abs, as it is dealing with [list] and is technically very similar to the other list abstractions I did.
I'm not really convinced that the PurePd objects should carry the same name as the externals they replace. I see, that these makes them instant replacements, however some externals like the infamous [counter] and [scale] are already in name-clash with differing functionality, and to add another version then doesn't seem right. I'd tend to prefer a prefix-namespace for such stuff, like I did for list-abs and also in rrad.ical (which has a rrad.scale.pd for example).
I like the sound of something like [pure.scale], which is attached (though still missing the log. scaling...)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Nov 19, 2005, at 5:09 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On Nov 18, 2005, at 6:14 PM, Frank Barknecht wrote:
At first I thought: No way, you'd need at least [list2symbol] for that, which is impossible to build with just internal objects. Then I said to myself: Hm, maybe it's not impossible? Then I said down and
it wasn't even that hard to do a [list2symbol] clone using just
builtins: list-2s.pd is attached. Oops, there goes another external previously used in RRADical ... ;)That's great! I've started a project I call "PurePd". Whenever I get inspired, I write a Pd patch that is a clone of a useful external. I just added it to abstractions/purepd and the build system. It would
be great if you could contribute this patch as [list2symbol] and anything else that you can think of. I have a Max-style [counter], [speedlim], and even a [metro] in the works.I already added it to the [list]-abs renamed to "list-l2s", because maybe there will be a "list-s2l" later, too. Although I currently think: No way to do this without externals, but who knows ... ;)
I think, in this case it feel natural to put it in [list]-abs, as it is dealing with [list] and is technically very similar to the other list abstractions I did.
I'm not really convinced that the PurePd objects should carry the same name as the externals they replace. I see, that these makes them instant replacements, however some externals like the infamous [counter] and [scale] are already in name-clash with differing functionality, and to add another version then doesn't seem right. I'd tend to prefer a prefix-namespace for such stuff, like I did for list-abs and also in rrad.ical (which has a rrad.scale.pd for example).
I like the sound of something like [pure.scale], which is attached (though still missing the log. scaling...)
Sorry, I should have mentioned this: I got geiger namespaces working in
my upcoming release. Its a simple patch to Pd actually. I am in the
process of documenting a "library directory" format, which is just a
directory with all of the help files and objects in it. The objects
can be in either .pd format or .pd_darwin/.pd_linux/.dll. You can use
it two ways: [purepd/scale] or -lib scale, then [scale]. The next
thing to do would be to make an [include]/[import] whatever object, so
that you could specify which libs your patch is using. I think Günter
had one sketched out.
I hope to have Windows, Linux, and MacOS X Pd-extended releases by the
end of the weekend with basic libdir functionality included. Its
already working on my machine. I'll be checking in a patch to
packages/patches soon.
.hc
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity."
-John Gilmore
On Sat, 19 Nov 2005, Hans-Christoph Steiner wrote:
it two ways: [purepd/scale] or -lib scale, then [scale]. The next thing to do would be to make an [include]/[import] whatever object, so that you could specify which libs your patch is using. I think Günter had one sketched out.
Yeah, I had one, but now if I look for it I only find the compiled pd_linux version (it was called "using"). It wasn't too hard to write, but I fear I won't have the time to do so soon (already bad consience because of reading the list).
Guenter
I hope to have Windows, Linux, and MacOS X Pd-extended releases by the end of the weekend with basic libdir functionality included. Its already working on my machine. I'll be checking in a patch to packages/patches soon.
.hc
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
That's great! I've started a project I call "PurePd". Whenever I get inspired, I write a Pd patch that is a clone of a useful external. I just added it to abstractions/purepd and the build system. It would be great if you could contribute this patch as [list2symbol] and anything else that you can think of. I have a Max-style [counter], [speedlim], and even a [metro] in the works.
have you done any benchmarks?
t
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
That's great! I've started a project I call "PurePd". Whenever I get inspired, I write a Pd patch that is a clone of a useful external. I just added it to abstractions/purepd and the build system. It would be great if you could contribute this patch as [list2symbol] and anything else that you can think of. I have a Max-style [counter], [speedlim], and even a [metro] in the works.
have you done any benchmarks?
I intend to do a benchmark session on all the list abs, that have equivalents in other libraries like Zexy. I'm curious, how much slower the abstraction versions actually are and which of them maybe should be included directly into Pd's [list], because the performance hit is too big.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Sun, 20 Nov 2005, Frank Barknecht wrote:
I intend to do a benchmark session on all the list abs, that have equivalents in other libraries like Zexy. I'm curious, how much slower the abstraction versions actually are and which of them maybe should be included directly into Pd's [list], because the performance hit is too big.
I think that the ones which should be put directly in [list] are either the ones who have bad time orders (e.g. the duration of the operation is proportional to the square of the number of elements...), or just the ones which are used most often in high-speed situations (even if indirectly).
Better again is to try figuring out what else could be coded in C in a way that abstractions can use it and become faster and so need not be recoded in C themselves. It's all about having as little C as possible.
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
On Nov 20, 2005, at 2:09 PM, Mathieu Bouchard wrote:
On Sun, 20 Nov 2005, Frank Barknecht wrote:
I intend to do a benchmark session on all the list abs, that have equivalents in other libraries like Zexy. I'm curious, how much slower the abstraction versions actually are and which of them maybe should
be included directly into Pd's [list], because the performance hit is too big.I think that the ones which should be put directly in [list] are either the ones who have bad time orders (e.g. the duration of the operation
is proportional to the square of the number of elements...), or just the
ones which are used most often in high-speed situations (even if
indirectly).Better again is to try figuring out what else could be coded in C in a
way that abstractions can use it and become faster and so need not be
recoded in C themselves. It's all about having as little C as possible.
You took the works right out of my mouth! I think that once we start
thinking about Pd as a language in itself, then people will start to
think how to optimize it as well. There is no doubt in my mind that C
code would be faster than Pd for most things, but, like Java, Ruby,
SmallTalk, there is something to be gained by using it to program.
Assembly is even faster than C, so why aren't people writing objects in
assembly?
.hc
http://at.or.at/hans/
Assembly is even faster than C, so why aren't people writing objects in assembly?
They are.
best, Thomas
On Nov 21, 2005, at 3:24 PM, Thomas Grill wrote:
Assembly is even faster than C, so why aren't people writing objects
in assembly?They are.
Are there any externals written entirely in assembly? I am sure there
are some written in C with some assembly, but that's like using Pd with
some C objects ;).
.hc
News is what people want to keep hidden and everything else is
publicity.
- Bill Moyers
Hans-Christoph Steiner schrieb:
On Nov 21, 2005, at 3:24 PM, Thomas Grill wrote:
Assembly is even faster than C, so why aren't people writing objects in assembly?
They are.
Are there any externals written entirely in assembly? I am sure there are some written in C with some assembly, but that's like using Pd with some C objects ;).
Oh yes indeed, we should really stop that....
Thomas
Thomas Grill wrote:
Hans-Christoph Steiner schrieb:
On Nov 21, 2005, at 3:24 PM, Thomas Grill wrote:
Assembly is even faster than C, so why aren't people writing objects in assembly?
They are.
Are there any externals written entirely in assembly? I am sure there are some written in C with some assembly, but that's like using Pd with some C objects ;).
Oh yes indeed, we should really stop that....
...and of course for ultimate performance a lot of the externals could be built using ICs and transistors ;) It seems like the original inspiration for max and pd must have come from those digital logic trainer boards with lots of boxes and banana plugs.
Martin
Marc Lavallée wrote:
Le 21 Novembre 2005 15:08, Hans-Christoph Steiner a écrit :
Assembly is even faster than C, so why aren't people writing objects in assembly?
Because assembly is unreadable, like some PD patches.
...and not portable, you need to write different code for each processor, whereas a C compiler can take c code and make the appropriate assembly from it. So c objects end up written in assembly anyway. The only advantage in writing directly in assembly is if you think you can write better code than the compiler, which was quite possible in the past, but nowadays not so easy.
Martin
Martin Peach schrieb:
Marc Lavallée wrote:
Le 21 Novembre 2005 15:08, Hans-Christoph Steiner a écrit :
Assembly is even faster than C, so why aren't people writing objects in assembly?
Because assembly is unreadable, like some PD patches.
...and not portable, you need to write different code for each processor, whereas a C compiler can take c code and make the appropriate assembly from it. So c objects end up written in assembly anyway. The only advantage in writing directly in assembly is if you think you can write better code than the compiler, which was quite possible in the past, but nowadays not so easy.
Well, ever heard of atomic instructions and lockfree code? And how about SIMD?
Would you show me how to code that in C?
thanks, Thomas
Thomas Grill wrote:
Martin Peach schrieb:
Marc Lavallée wrote:
Le 21 Novembre 2005 15:08, Hans-Christoph Steiner a écrit :
Assembly is even faster than C, so why aren't people writing objects in assembly?
Because assembly is unreadable, like some PD patches.
...and not portable, you need to write different code for each processor, whereas a C compiler can take c code and make the appropriate assembly from it. So c objects end up written in assembly anyway. The only advantage in writing directly in assembly is if you think you can write better code than the compiler, which was quite possible in the past, but nowadays not so easy.
Well, ever heard of atomic instructions and lockfree code? And how about SIMD?
Well I said it's not so easy...
Would you show me how to code that in C?
I think intel released a compiler that would specifically use SIMD, and I always believed the commercial compilers also used them when asked as part of the optimisation. So whenever you want multiple instruction processing you need to declare variables as arrays of multiples of four and the compiler will optimize as parallel instructions...See this: http://ds9a.nl/gcc-simd/fp-simd-builtins.html I would guess that thread libraries implement the locking and atomicity in assembly so I don't need to worry about it, but I haven't gotten there yet...Possibly future versions of the c standard will include keywords for threading support.
Martin
thanks, Thomas
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I think intel released a compiler that would specifically use SIMD, and I always believed the commercial compilers also used them when asked as part of the optimisation. So whenever you want multiple instruction processing you need to declare variables as arrays of multiples of four and the compiler will optimize as parallel instructions...See this: http://ds9a.nl/gcc-simd/fp-simd-builtins.html
these pseudo-codelets also exist for MSVC and they are a real pain... you wouldn't want to use the code once you disassembled it.
all the best, Thomas
On Mon, 21 Nov 2005, Thomas Grill wrote:
these pseudo-codelets also exist for MSVC and they are a real pain... you wouldn't want to use the code once you disassembled it.
Personally, all my MMX code is compiled, er, assembled I mean, by NASM.
But that assembly language isn't source code, because it's generated by a Ruby script.
That's the stuff I coded in 2003 in order to accelerate GridFlow.
I might end up using GCC instead of NASM, but there isn't that much of a reason to: it's not any more portable than the asm, and then using GCC makes it more difficult for me to go to the next level, that is, self-modifying code.
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
On Mon, 21 Nov 2005, Hans-Christoph Steiner wrote:
Assembly is even faster than C, so why aren't people writing objects in assembly?
hello_text: db "hello, %s!",10,0
hello_symbol: push ebp mov ebp,esp mov esi,[ebp+12] ; a t_symbol* push [esi] ; a char* push hello_text call post add esp,8 fpush 42.0 mov ebx,[ebp+8] ; a t_hello* push [ebx+32] ; a t_outlet* call outlet_float add esp,8 pop ebp ret
You may consider this as a warning!!!
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
You took the works right out of my mouth! I think that once we start thinking about Pd as a language in itself, then people will start to think how to optimize it as well. There is no doubt in my mind that C code would be faster than Pd for most things, but, like Java, Ruby, SmallTalk, there is something to be gained by using it to program. Assembly is even faster than C, so why aren't people writing objects in assembly?
well, it's clear, that it's absolutely nonsense to write some stuff in a low-level language like c or assembler. aspects are:
- coding speed
- runtime speed
- code readability / maintainability
- level of abstraction
i wouldn't write a some control logic of a composition or installation in asselber, nor would i write a frequently used message-object in pd or any of the high-level scripting languages like guile, python or ruby...
using assembler has 2 features:
- runtime speed (simd)
- full access to the architecture (there are machine features, that no
language i know implements)
t
On Nov 19, 2005, at 6:34 PM, Tim Blechmann wrote:
That's great! I've started a project I call "PurePd". Whenever I get inspired, I write a Pd patch that is a clone of a useful external. I just added it to abstractions/purepd and the build system. It would be great if you could contribute this patch as [list2symbol] and anything else that you can think of. I have a Max-style [counter], [speedlim], and even a [metro] in the works.
have you done any benchmarks?
No, that's not really my interest, but it would be good to know. I am
interested in making Pd a full-fledged programming language written in
Pd as much as possible. I'll leave the optimization to those who are
good at it.
.hc
t
--
mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tklatest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity."
-John Gilmore
That's great! I've started a project I call "PurePd". Whenever I get
inspired, I write a Pd patch that is a clone of a useful external. I
just added it to abstractions/purepd and the build system. It would be
great if you could contribute this patch as [list2symbol] and anything
else that you can think of. I have a Max-style [counter], [speedlim],
and even a [metro] in the works.
its a nice ideal, but i cant help but think we'd end up with something performing more like ruby than a realtime media system if 'everything is an abstraction' and the core just defined syntax. i mean the few times i rewrote things in pd - [hsv2rgb] and [sprintf] - they ended up about 10 times slower.. and thats not even dealing with a fraction of the bandwidth of audio or video..
maybe theres a way to byte-compile them down to get some of the performance back, a la .pyc or .elc...but that sounds more like a PhD project...
I have also started writing objects in Pd that make writing objects in
Pd much easier. Things like [float_argument] and [symbol_argument]
which handle receiving arguments, and can distinguish between when the
object is instantiated with an argument, and when it is not. Other
ideas I have for patches in this genre are a debug objects that can be
controlled locally or by a global send/receive. Also, I have been
sketching out print_error and print_version objects.I need a new name for this second project now, since it makes sense to
keep it distinct from PurePd. "libtools" comes to mind....
awfully reminiscent of 'libtool'.. i guess instead of libtoolize you could have libtoolsize, or PurePdIze, to instantly convert all your C objects into PD objects, and get the real-time gratification of a 80% performance loss..
.hc
http://at.or.at/hans/
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, carmen hat gesagt: // carmen wrote:
its a nice ideal, but i cant help but think we'd end up with something performing more like ruby than a realtime media system if 'everything is an abstraction' and the core just defined syntax. i mean the few times i rewrote things in pd - [hsv2rgb] and [sprintf]
- they ended up about 10 times slower.. and thats not even dealing
with a fraction of the bandwidth of audio or video..
Of course we all know, that patched stuff id Pd is slower than coding stuff in C. Still we patch in Pd, why do we do it? Because performance is not all that matters, ease of programming, the ability to change an implementation on the fly etc. - all that is important as well and it is the major reason, scripting languages are taking over large parts of software development: The performance of the programmer is becoming the much more important bottleneck than the performance of the CPU.
Of course this shouldn't stop us from trying to sort out the bottlenecks in our patches and where those can be fixed by coding a C external.
For example, when patching the [list]-abs I found, that I am using the serialize operation [list-drip] *a lot*. I now did a benchmark and saw, that serializing as done in the help patch is slower by a large deal than the equivalent operation in Zexy. (Benchmark patches attached). So including a [list serialize] or [list drip] in MAIN-Pd would give a big performance boost. OTOH it is possible to get this boost right now, if it's important, by replacing the serialization in [list-drip] with zexy's drip. As all [list]-abs use the [list-drip] abstraction, this will accelerate all of them immediatly.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
For example, when patching the [list]-abs I found, that I am using the serialize operation [list-drip] *a lot*. I now did a benchmark and saw, that serializing as done in the help patch is slower by a large deal than the equivalent operation in Zexy. (Benchmark patches attached).
Attached is a slightly enhanced benchmark, which now gives hard numbers about the [cputime] spent.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Of course we all know, that patched stuff id Pd is slower than coding stuff in C. Still we patch in Pd, why do we do it? Because performance is not all that matters, ease of programming, the ability to change an implementation on the fly etc. - all that is important as well and it is the major reason, scripting languages are taking over large parts of software development: The performance of the programmer is becoming the much more important bottleneck than the performance of the CPU.
right ... but that's why i think, reimplementing an external in pd is a waste of time. if there _is_ working c code, that's fine to use and, why shouldn't one just use it...
cheers ... tim
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
Of course we all know, that patched stuff id Pd is slower than coding stuff in C. Still we patch in Pd, why do we do it? Because performance is not all that matters, ease of programming, the ability to change an implementation on the fly etc. - all that is important as well and it is the major reason, scripting languages are taking over large parts of software development: The performance of the programmer is becoming the much more important bottleneck than the performance of the CPU.
right ... but that's why i think, reimplementing an external in pd is a waste of time. if there _is_ working c code, that's fine to use and, why shouldn't one just use it...
I don't want to forbid using externals at all, using - and writing - externals is as much part of Pd as patching is. However an external is a black box. Unless you know C, you cannot change its behaviour, even if you only want to add a little feature. Also seeing the algorithm at work in a graphical format can help with understanding it. You don't even need a help patch to see, how many abstractions work.
Then we have the problem with name clashes, which funnily occur mostly in trivial cases like the [counter]. Why write different versions of [counter]? Why write a simple [counter] external at all, when it's easier to do using [f] and [+]?
Most importantly though: Not everyone has every external installed. This is a real problem which I learned the hard way with RRADical, where in the beginning I said to myself: Go crazy and use every external there is to do the work. This was a bad mistake, because now all the time people come asking (me) how to compile the needed externals on Windows and I cannot help them. That's why I'm working on replacing most of the stuff used in RRADical with builtin objects. Unfortunatly there is nothing that can replace [pool] and [OSC] in Pd yet, and I don't want to ditch OSC support in RRADical and I cannot ditch [pool], which is a constant pool of trouble for non-technically inclined users. :(
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hey Frank,
Unfortunatly there is nothing that can replace [pool] and [OSC] in Pd yet, and I don't want to ditch OSC support in RRADical and I cannot ditch [pool], which is a constant pool of trouble for non-technically inclined users. :(
you are right, and i'm constantly trying to improve the docs and building process. Unfortunately the feedback concerning hints what to improve in which way is close to nothing. All i can do then is try to figure out the paths that non-technical users are taking which sometimes is hard to imagine, because they are too individual.
best greetings, Thomas
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
Hey Frank,
Unfortunatly there is nothing that can replace [pool] and [OSC] in Pd yet, and I don't want to ditch OSC support in RRADical and I cannot ditch [pool], which is a constant pool of trouble for non-technically inclined users. :(
you are right, and i'm constantly trying to improve the docs and building process. Unfortunately the feedback concerning hints what to improve in which way is close to nothing. All i can do then is try to figure out the paths that non-technical users are taking which sometimes is hard to imagine, because they are too individual.
That's so true. For you and me and many others here, running "sh build.sh pd gcc" is not a big deal at all, but well ...
However with the effort of Hans and James etc. to package Pd with externals this really should become less of a problem soon.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
I don't want to forbid using externals at all, using - and writing - externals is as much part of Pd as patching is. However an external is a black box. Unless you know C, you cannot change its behaviour, even if you only want to add a little feature. Also seeing the algorithm at work in a graphical format can help with understanding it. You don't even need a help patch to see, how many abstractions work.
I'm in total agreement here. One thing that makes PD accessible to otherwise non-programmers is the difference between a written syntax and a visual one. And more often than not, artists think visually. Laying out more of the basic, underlying structure of PD in a visual form , and allowing them to make changes in it visually, DOES help them understand it better.
Unfortunatly there is nothing that can replace [pool] and [OSC] in Pd yet, and I don't want to ditch OSC support in RRADical and I cannot ditch [pool], which is a constant pool of trouble for non-technically inclined users. :(
Perhaps [col] is a possibility? I don't know if it can replicate all the functionality of [pool], but it is easier to compile. It's still an external, however, and it would be great to see this kind of stuff handled more easily in PD some day.
best, d.
On Sun, 20 Nov 2005, Frank Barknecht wrote:
That's why I'm working on replacing most of the stuff used in RRADical with builtin objects. Unfortunatly there is nothing that can replace [pool] and [OSC] in Pd yet, and I don't want to ditch OSC support in RRADical and I cannot ditch [pool], which is a constant pool of trouble for non-technically inclined users. :(
Is it possible to run MinGW or Cygwin or (GASP!) MSVC6 on Linux, through WINE ?
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
That's why I'm working on replacing most of the stuff used in RRADical with builtin objects. Unfortunatly there is nothing that can replace [pool] and [OSC] in Pd yet RRADical and I cannot ditch [pool], which is a constant pool of trouble for non-technically inclined users. :(
Is it possible to run MinGW or Cygwin or (GASP!) MSVC6 on Linux, through WINE ?
no WINE needed: (not sure what the x is for, maybe x-compile.)
)maybe when hans finishes porting his packager to QNX he could take a look at it..
dev-util/xmingw-binutils Latest version available: 2.15.94.20050118.1 Latest version installed: [ Not Installed ] Size of downloaded files: 14,911 kB Homepage: http://sources.redhat.com/binutils/ Description: Tools necessary to build Win32 programs License: || ( GPL-2 LGPL-2 )
dev-util/xmingw-gcc Latest version available: 3.4.4 Latest version installed: [ Not Installed ] Size of downloaded files: 28,371 kB Homepage: http://www.gnu.org/software/gcc/gcc.html Description: The GNU Compiler Collection - i386-mingw32msvc-gcc only License: GPL-2 LGPL-2.1
dev-util/xmingw-runtime Latest version available: 3.7 Latest version installed: [ Not Installed ] Size of downloaded files: 281 kB Homepage: http://www.mingw.org Description: Free Win32 runtime and import library definitions License: BSD
dev-util/xmingw-w32api Latest version available: 3.2 Latest version installed: [ Not Installed ] Size of downloaded files: 1,338 kB Homepage: http://www.mingw.org Description: Free headers and libraries for the Win32 API License: BSD
Mathieu Bouchard - t?l:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montr?al QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Nov 22, 2005, at 11:15 PM, Mathieu Bouchard wrote:
On Sun, 20 Nov 2005, Frank Barknecht wrote:
That's why I'm working on replacing most of the stuff used in RRADical with builtin objects. Unfortunatly there is nothing that can replace [pool] and [OSC] in Pd yet, and I don't want to ditch OSC support in RRADical and I cannot ditch [pool], which is a constant pool of
trouble for non-technically inclined users. :(Is it possible to run MinGW or Cygwin or (GASP!) MSVC6 on Linux,
through WINE ?
You can compile for MinGW on Linux and OSX, probably cygwin too. I
doubt MSVC runs in WINE, but maybe.
How does that relate to the above bit tho? Actually, anyone got Pd
compiling with MinGW? I could use some pointers.
.hc
"The arc of history bends towards justice."
- Dr. Martin Luther King, Jr.
How does that relate to the above bit tho?
so you can set up a machine to autobuild for all 3 platforms (theres tutorials on cross-compiling for OSX from linux, and we know mingw works..) since you know.. development goes so fast that people want nightly builds
Actually, anyone got Pd
compiling with MinGW? I could use some pointers.
sure, theres a SConscript in devel_0_39 and theres also a makefile.mingw maybe in devel_0_38. just ./configure && make && make install the deps like tk and such first, although you can use a static path to MSVC-generated .libs if you dont feel like doing that..
.hc
"The arc of history bends towards justice." - Dr. Martin Luther King, Jr.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Nov 23, 2005, at 1:23 AM, carmen wrote:
How does that relate to the above bit tho?
so you can set up a machine to autobuild for all 3 platforms (theres
tutorials on cross-compiling for OSX from linux, and we know mingw
works..) since you know.. development goes so fast that people want
nightly buildsActually, anyone got Pd compiling with MinGW? I could use some pointers.
sure, theres a SConscript in devel_0_39 and theres also a
makefile.mingw maybe in devel_0_38. just ./configure && make && make
install the deps like tk and such first, although you can use a static
path to MSVC-generated .libs if you dont feel like doing that..
Tcl builds fine, but I can't get Tk to find what it needs in the Tcl
build. It doesn't work if I point --with-tcl to tcl/win or
/usr/local/lib. Any tips? Everything I found online hasn't worked.
THen I can add it to the howto:
http://puredata.org/docs/developer/win
.hc
.hc
__ ____
"The arc of history bends towards justice." - Dr. Martin Luther King,Jr.
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
"Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war on
terrorism."
-
retired U.S. Army general, William Odom
On Sun, 20 Nov 2005, Frank Barknecht wrote:
would give a big performance boost. OTOH it is possible to get this boost right now, if it's important, by replacing the serialization in [list-drip] with zexy's drip. As all [list]-abs use the [list-drip] abstraction, this will accelerate all of them immediatly.
Or for the same reason by using the "serialize" object from ggee, which might have been an inspiration for Johannes' drip. But then it might have not, sometimes people just do the same thing at the same time in different places without knowing. In any case it might be a sign of the usefullness of the object.
Guenter
Hallo, gÃŒnter geiger hat gesagt: // gÃŒnter geiger wrote:
On Sun, 20 Nov 2005, Frank Barknecht wrote:
would give a big performance boost. OTOH it is possible to get this boost right now, if it's important, by replacing the serialization in [list-drip] with zexy's drip. As all [list]-abs use the [list-drip] abstraction, this will accelerate all of them immediatly.
Or for the same reason by using the "serialize" object from ggee, which might have been an inspiration for Johannes' drip. But then it might have not, sometimes people just do the same thing at the same time in different places without knowing. In any case it might be a sign of the usefullness of the object.
However [serialize] works the other way around, by turning a stream of floats into a list. In Zexy a similar object is called [repack], however repack starts a new list as soon as the specified length is reached and then waits until the new list is filled.
In [list]-abs I have [list-lastx] which basically is the same as your [serialize], additionally it also accepts symbol atoms to pack into the list. A [repack] clone is not part of [list]-abs (yet), but it's simply done using a:
[list prepend]X[t a]
Zexy's drip and my [list-drip] "unpack" a list, that is, they spit out each element of a list after another. [list-drip] has a IMO quite useful second outlet which sends a bang, after the whole input list was consumed.
Regarding the usefulness: All my newer patches use at least one [list] object. And regarding the usefulness of [list-drip]: Of the currently 40 list-abstractions 19 use a kind of "drip".
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Mon, 21 Nov 2005, Frank Barknecht wrote:
Hallo, günter geiger hat gesagt: // günter geiger wrote:
On Sun, 20 Nov 2005, Frank Barknecht wrote:
would give a big performance boost. OTOH it is possible to get this boost right now, if it's important, by replacing the serialization in [list-drip] with zexy's drip. As all [list]-abs use the [list-drip] abstraction, this will accelerate all of them immediatly.
Or for the same reason by using the "serialize" object from ggee, which might have been an inspiration for Johannes' drip. But then it might have not, sometimes people just do the same thing at the same time in different places without knowing. In any case it might be a sign of the usefullness of the object.
However [serialize] works the other way around, by turning a stream of floats into a list.
Ooops. Thats true, but it shouldn't be this way. Sorry, I haven' t used these objects for a long time and obviously the CVS contains the wrong code.
Guenter
In Zexy a similar object is called [repack], however repack starts a new list as soon as the specified length is reached and then waits until the new list is filled.
In [list]-abs I have [list-lastx] which basically is the same as your [serialize], additionally it also accepts symbol atoms to pack into the list. A [repack] clone is not part of [list]-abs (yet), but it's simply done using a:
[list prepend]X[t a]
Zexy's drip and my [list-drip] "unpack" a list, that is, they spit out each element of a list after another. [list-drip] has a IMO quite useful second outlet which sends a bang, after the whole input list was consumed.
Regarding the usefulness: All my newer patches use at least one [list] object. And regarding the usefulness of [list-drip]: Of the currently 40 list-abstractions 19 use a kind of "drip".
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 Mon, 21 Nov 2005, Frank Barknecht wrote:
In Zexy a similar object is called [repack], however repack starts a new list as soon as the specified length is reached and then waits until the new list is filled.
For the record, that's like [#import]->[#export_list] in GF.
A [repack] clone is not part of [list]-abs (yet), but it's simply done using a: [list prepend]X[t a]
That's a O(n^2) operation, which means it's sloooow, especially for big lists.
Also, I'd vote in favour of allowing the self-connecting an object, so that we don't have to use [t a] or whatever as a kludge to pretend that what we want is not connecting an object to itself. It would simplify [list prepend]X[t a] and also [+]X[t f] and also [max]X[t f] and such. However it wouldn't simplify [f]X[+].
Zexy's drip and my [list-drip] "unpack" a list, that is, they spit out each element of a list after another.
For the record, that's like [foreach] in GF. That's also like [#export] in GF (but #export is made for integers and can also handle floats if you tell it to but it doesn't do symbols nor pointers).
[list-drip] has a IMO quite useful second outlet which sends a bang, after the whole input list was consumed.
That should be a standard feature.
And regarding the usefulness of [list-drip]: Of the currently 40 list-abstractions 19 use a kind of "drip".
There's a reason. Guess why I called it [foreach] in GF: it's because many languages have something like that, called either "foreach" or "for" or "each". Instead of having an outlet, they take a "code block" or "closure" or "function pointer" as an argument. Well, an outlet is pretty much like a souped-up function pointer, if you ask me.
(I'm studying relationships between Pd and other very different languages)
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
günter geiger wrote: ...
might have been an inspiration for Johannes' drip. But then it might have not, sometimes people just do the same thing at the same time in different places without knowing. In any case it might be a sign of the usefullness of the object.
might have not, indeed... iter, pretty much like drip, was in Ircam Max since 2.01 (November 1990, exactly 15 years ago...)
Krzysztof
On Sun, 20 Nov 2005, carmen wrote:
its a nice ideal, but i cant help but think we'd end up with something performing more like ruby than a realtime media system if 'everything is an abstraction' and the core just defined syntax.
Funny, one of my early ideas when coding in Ruby has been that way too
much of the interpreter is coded in C and so that its builtin classes like
Array and Hash and String should be almost completely recoded in Ruby.
I've rewritten those and yes, they were much slower, but then they could
also be hacked in ways that the C version couldn't easily be. E.g. imagine
if, from Pd, you could create a variant of Pd's [table] class such that it
supports methods "undo" and "redo" ! Well, I've done exactly the
equivalent of that in the Ruby world.
maybe theres a way to byte-compile them down to get some of the performance back, a la .pyc or .elc...but that sounds more like a PhD project...
You don't need to make compilations to files. Those can remain in memory and recompiled at each load (or each modification of a patch). Examples of those are Perl, Tcl, YARV (Ruby2), and of course, the DSP in Pd/Max/jMax.
However, in PureData, the DSP is more readily optimisable than the message system. In particular, the DSP system has been designed to be so: that was rather natural, as it is a synchronous system with fixed bandwidth, so you preallocate all the RAM you need for object-to-object communication, and you need not do that again. Also, DSP does not have a prescribed order of execution, so it's potentially reorderable if the compiler thinks it's better to. DSP has many less runtime lookups because perform-funcs don't send their DSP blocks explicitly, so that can be planned in advance (short of Pd decompiling its externals at runtime...).
awfully reminiscent of 'libtool'.. i guess instead of libtoolize you could have libtoolsize, or PurePdIze,
I suggest that we trick the authors of libtool into renaming it to libstool. That's what should happen to a program that mostly just double the amount of diskspace required to compile a program. Sorry, I'm just feeling vengeful about my days of trying to use Linux on a 1.7 GB disk.
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
On Tue, 22 Nov 2005, Mathieu Bouchard wrote:
DSP has many less runtime lookups because perform-funcs don't send their DSP blocks explicitly, so that can be planned in advance (short of Pd decompiling its externals at runtime...).
read the end of that as:
... so that can be planned in advance, something which can't be done with the message system, short of Pd decompiling its externals at runtime.
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
On Sat, 19 Nov 2005, Hans-Christoph Steiner wrote:
I have also started writing objects in Pd that make writing objects in Pd much easier. Things like [float_argument] and [symbol_argument] which handle receiving arguments, and can distinguish between when the object is instantiated with an argument, and when it is not.
For that purpose, I think that Max's [patcherargs] should be cloned instead.
I need a new name for this second project now, since it makes sense to keep it distinct from PurePd. "libtools" comes to mind....
Why the name "libtools" ?
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
-
carmen -
Christian Klippel -
derek holzer -
Frank Barknecht -
Georg Holzmann -
günter geiger -
Hans-Christoph Steiner -
ian campbell -
Krzysztof Czaja -
Marc Lavallée -
Martin Peach -
Mathieu Bouchard -
Thomas Grill -
Tim Blechmann