[PD] poor performance when saving an abstraction when many copies are loaded in a patch

[IOhannes m zmoelnig]

hi again.

Chris McCormick wrote:
> 
>>> * No strings.
>> you mean, like C?
> 
> In C I can dynamically allocate an array of chars terminated by a \0
> *with spaces* as easily as:
> 
> char *mystring = "pants pants pants.";

as you have shown, there is no string type in C.
you (ab)use arrays of bytes (chars) as "strings".
miller has often argued, that strings in Pd are as simple as arrays of 
floats.
(true, a float is not an ideal representation of a glyph; but neither is 
a char)

i do not say, that i would handle strings in such a way.

> 
>>> * Audio processing is hard coded into it instead of being supported by the
>>> core language as a library like in 99% of other programming languages.
>> now that is a real bummer argument against bein a real programming 
>> language and bein unable to be used for large scale applications.
>>
>> please do not forget that most programming languages are text-based 
>> instead of graphical schnickschnack.
> 
> Most programming languages aren't highly optimised for the singular task
> of doing DSP processing though. 

correct.
but they might be optimized for other tasks. like list handling, or 
formulas or business (well, the latter is _rather_ a joke).

each and every language is good in something and bad in something else.
being good in something no-one else is good in, should imho be regarded 
as a feature rather than a bug.


> to develop applications, it just makes it slower and/or more awkward in
> some cases where a general purpose programming language would do better.
> The whole DSP bit is bloat if you're not using it for the task at hand.
> On the other hand, in the case of DSP, it doesn't get much better than
> Pd.
> 
>> and that true programming languages exclusively run on mainframes.
> 
> Say what?

this was a joke, because it seemed to me, that your arguments became 
arbitrary.

> 
>>> * It's not easily portable to embedded systems without many modifications.
>> which modifications?
> 
> The PDa source code is different enough from the mainline Pd source code
> that it makes it quite hard to integrate mainline Pd releases back into
> PDa.

this is a problem of the implementation not of the "language".


it is also a social problem as to how to get which changes into 
pd-vanilla. (e.g. i still think that it would be (or rather have been) 
possible to get the PDa changes into pd proper; it was not done though)

> 
>> how is this with other programming languages?
> 
> That depends on the implementation and target platform really. I found
> Python particularly difficult to port to the Nintendo DS, but I found
> other programs were as easy as using the --host= flag with the configure
> script. However, Lua, the Java VM, and Scheme have been ported to heaps
> of platforms so it should in general be something that doesn't require
> a fork of the codebase like PDa.
> 
> This isn't something that would stop most people from using Pd as a
> programming language, just those of us targetting embedded systems and
> systems with no OS.

otoh, there are few powerful DSP/music-centric languages available on 
embedded systems apart from Pd. choose one of SC3, max/msp, OSW, chuck 
and try to run it.


> 
>> are you talking about programs written in Pd or the engine that runs 
>> these programs?
> 
> The engine.
> 
>> compared to C, i consider Pd-patches _quite_ portable...
> 
> Yep, although regular Pd patches won't just run without any changes in
> PDa always since some objects don't work in PDa. 

please file a bug-report for PDa :-)

> Also, numbers behave
> differently, which is pretty annoying.

true.



> 
>> and then, i have never tried to port a java-vm to an embedded system. 
>> don't know how many modifications this takes compared to the plain 
>> i386-machine.
> 
> The Java-VM has been ported to heaps and heaps of systems, so there
> is probably an implementation out there for whichever system you want
> (there have even been CPUs developed that directly speak the bytecode)

that's not the point.
just because somebody already did the work, it doesn't mean that it has 
not been a pain to do.

> Yes, you are quite right. How about inheritance and polymorphism for

correct.
but Pd is not an OOP-language (despite using "objects")
even though OOP-languages are still quite modern, there _are_ other 
useful languages that are not OOP.

and i would be interested to hear ideas on how to get OOP into a 
patcher-like languages.



mfg.a
IOhannes