[PD] sending image from of / libpd

[Mathieu Bouchard]

On Sun, 28 Aug 2011, Peter Brinkmann wrote:

> One major simplification is the use of built-in data types vs custom 
> structs and unions.

You mean you simplify by making things more low-level ?

const char * is rarely ever called high-level...

> With this transition to built-in data types, you can simply run SWIG on 
> the header file and automatically create bindings for a significant part 
> of libpd for lots of target languages; only the callbacks will require 
> some additional work.  Without this conversion, you would have to 
> descend into the netherworld of custom typemaps and such.

When you are using typemaps, do you have the impression that you're using 
SWIG in a high-level way ? Isn't the lack of typemaps a sign that your 
API isn't very abstract ?

> Incidentally, I've also gotten flak for not baking any multi-instance 
> support into the initial version of libpd (I did consider it, but it 
> seemed pointless because with the current version of Pd it would still 
> have just one single instance).

The point would be to make all the backward-compat and forward-compat you 
need for supporting a future version of pd that will include features that 
you're already thinking about.

But you don't have to add an argument everywhere. I bet that you'll add a 
libpd_set_current_pd_instance(t_pd_interpreter *) function that will set a 
global variable used by the rest of the pd api. That would be consistent 
with the stateful message-passing in many small steps using a hidden 
global array. Later you can make all of that thread-safe by making all of 
those functions call pthread_self() to figure out which thread they're in, 
and replace the globals by threadwise-locals.

> I figure that as long as I'm drawing fire from both low-level C hackers 
> and high-level OOP types, I must be doing something right;)

It's bad to insist on a low-level vs high-level dichotomy. It's been quite 
a while that those words cause confusion because they give the impression 
that those levels are all stacked in top of each other along one axis of 
highness. The truth is a lot more complicated, in which levels aren't 
well-defined, more abstract isn't necessarily better, more concrete isn't 
necessarily better either, it depends a lot on what you want to achieve, 
and what you expect for the future, etc. ; I still use expressions like 
low-level or high-level sometimes, but it isn't as seriously as when 
people first invented the term.

So, it's possible that you're doing something right, but drawing fire from 
people that you categorise in two bins is probably not a good sign of what 
you think it is.

> It's more of a general consideration, and I don't have any road map in 
> mind.  Right now I'm just hoping to have a conversation about this.

Well, does that involve multiple interpreters, with one interpreter per 
core, but still in the same process, with a way to pass messages quickly 
from one interpreter to the other ?

Would they be sharing the same gensym, or would they need to re-gensym 
everything when talking from one interpreter to the other ?

  _______________________________________________________________________
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC