hi,
in Pd proper, there are many globals seen by linux externals, but which are hidden from `nt' dlls, because of the lack of explicit exporting directive.
I would like to use the routines: binbuf_match(), canvas_obj() (and probably also the outmidi_ set), and the variables: subcanvas_class, and newest, while retaining the possibility of a future `nt' port.
Are they part of PureData EPI (externals programming interface) or their omission has been intended?
Krzysztof
In general, my intention is to "stabilize" only the routines that are profiled in m_pd.h, and not to consider everything else as internal and changeable.
I think each such routine should be considered in its own right... making binbuf_match available (and comitting to its design) seems appropriate; I'm not sure about canvas_obj() -- that should be part of an API to allow externs to edit patches in general; and the MIDI stuff is probably best kept private since it's best to have all MIDI go explicitly to a MIDI object in the patch from the user's perspective.
cheers Miller
On Tue, Nov 20, 2001 at 04:15:09PM +0100, Krzysztof Czaja wrote:
hi,
in Pd proper, there are many globals seen by linux externals, but which are hidden from `nt' dlls, because of the lack of explicit exporting directive.
I would like to use the routines: binbuf_match(), canvas_obj() (and probably also the outmidi_ set), and the variables: subcanvas_class, and newest, while retaining the possibility of a future `nt' port.
Are they part of PureData EPI (externals programming interface) or their omission has been intended?
Krzysztof
hi Miller, thanks for the clarification!
Currently one and only important obstacle blocking my nt port is the variable `newest'. Would you consider providing an access function to this one?
Miller Puckette wrote:
In general, my intention is to "stabilize" only the routines that are profiled in m_pd.h, and not to consider everything else as internal and changeable.
What about the g_canvas.h stuff? And how about using m_imp.h by the adventurous coders of externals, willing to maintain their code in sync with Pd releases? Otherwise, what is the purpose of all those EXTERN declarations in m_imp.h?
I think each such routine should be considered in its own right... making binbuf_match available (and comitting to its design) seems appropriate;
fine, so for the time being I will just #ifdef NT-in an exact copy taken from m_binbuf.c...
I'm not sure about canvas_obj() -- that should be part of an API to allow externs to edit patches in general;
there is a simple workaround of typedmess(<canvas>, gensym("obj"), ...
[...] and the MIDI stuff is probably best kept private since it's best to have all MIDI go explicitly to a MIDI object in the patch from the user's perspective.
that is very much true. Btw. direct access to MIDI output is wide open through sys_putmidibyte|mess routines (bypassing dejittering queue). Anyway, I do not need it. Thanks again.
Krzysztof
-
Krzysztof Czaja -
Miller Puckette