hi miller,
as you know, there are externals using g_canvas.h. after you recent
update, it's impossible to use g_canvas.h in c++ code (like flext),
since template is a reserved keyword in c++...
EXTERN void template_notify(t_template *template,
t_symbol *s, int argc, t_atom *argv);
EXTERN t_float fielddesc_getcoord(t_fielddesc *f, t_template *template,
t_word *wp, int loud);
EXTERN void fielddesc_setcoord(t_fielddesc *f, t_template *template,
t_word *wp, float pix, int loud);
fixed in devel ... tim
--
mailto:TimBlechmann@gmx.de ICQ: 96771783
http://www.mokabar.tk
latest 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
hi all,
is it only my machine, or does pd somehow get into a bad state if i
enter a '{' character to a message box?
after entering a {, pd doesn't react any more ...
reproduced on 0.38-4 and devel_0_39 ...
cheers ... tim
--
mailto:TimBlechmann@gmx.de ICQ: 96771783
http://www.mokabar.tk
latest 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
hi carmen and all other devel developers ..
the recently checked in pd.tk might clash with the real pd.tk, that's a
copy of u_main.tk.
since it breaks some devel installations (i've spent some time on irc
yesterday), carmen, i think you introduced this file ... please try to
find another way to distinguish between u_main.tk and pd.tk, that
doesn't result in a nameclash ...
thanks ... tim
--
mailto:TimBlechmann@gmx.de ICQ: 96771783
http://www.mokabar.tk
latest 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
Greetings,
I'm trying to output a list of atoms, and I get a
consistency check failed whenever I run my external.
the line in the _perform function is:
/* to set up the list */
float parcors[ord];
/* to outlet the list */
outlet_list(x->x_obj.ob_outlet,gensym("list"),ord,parcors);
/* and in _new */
outlet_new(&x->x_obj, &s_list);
and then I get the following from the compiler:
warning: passing arg 4 of `outlet_list' from
incompatible pointer type
...so what am I doing wrong?
Best,
Ed
->
-->
---->
------->
------------>
--------------------> r3search + praktik EK5perimenz
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
I'm trying to understand Pd's low-level I/O but I'm
very confused. I think I've narrowed it down to
s_stuff.h and d_dac.c but I'm not sure. Can anybody
help me with this and is there any Pd code with
extensive comments? I don't mind using another
low-level API... for example I'm very familiar with
the I/O of writing Pd externals but I need to
starting writing stand-alone Windows programs. I'm
good with JACK but I believe that's Linux only. Anyway
thanks for the help!
Scott
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
hi,
Am Freitag 19 August 2005 00:03 schrieb Miller Puckette:
> Hi all,
>
> Pd 0.39 test 5 is out. Main changes are better protection against losing
> edited files and many small bug fixes. I'm hoping to add no more features,
> only fix bugs, and get the "real" 0.39 out in a week or so.
>
there are two points that make the compilation with gcc 2.95 fail:
in s_inter.c around line 290, the "struct rlimit mlock_limit;" should move to
the top of the function block:
void sys_set_priority(int higher)
{
#ifdef _POSIX_MEMLOCK
/* tb: force memlock to physical memory { */
struct rlimit mlock_limit;
#endif
and in s_midi_alsa.c, around line 94, "snd_seq_client_info_t *alsainfo;"
should also move to the beginnng of the block:
void sys_alsa_do_open_midi(int nmidiin, int *midiinvec,
int nmidiout, int *midioutvec)
{
snd_seq_client_info_t *alsainfo;
> http://www-crca.ucsd.edu/~msp/software.html
>
> cheers
> Miller
>
greetings,
chris
Bugs item #1263139, was opened at 2005-08-18 17:28
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1263139&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: zexy
Group: None
Status: Open
Resolution: None
Priority: 1
Submitted By: Frank Barknecht (fbar)
Assigned to: IOhannes m zmölnig (zmoelnig)
Summary: Startup messages too verbose
Initial Comment:
Hi Iohannes,
this is a wishlist bug: Since Zexy2 single Zexy
externals in the path spit out a lot of messages like:
[a2l]
part of zexy-2.1
Copyright (l) IOhannes m zmölnig, 1999-2005
forum::für::umläute
IEM
compiled: Aug 5 2005
...
when Pd is started. This makes it hard to read anything
important that came before zexy is loaded, for example,
if Midi devices were found etc.
My wish would be to follow the "no news is good news"
approach and not print these messages or make them a
lot shorter.
Thanks,
Frank
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1263139&group_…
hi all,
i'm currently thinking about an elegant way to get rid of the problem of
ordering loadbangs.
from what i understand, at the moment, there is only the following order
of loadbangs:
abstractions, subpatches, canvas.
but having two sub-patches, i can't be sure, which one is loadbanged
first. this can be a problem when having abstractions that should be
initialized from other abstractions somewhere in pd (not from a parent
canvas).
thus i'd propose the following:
there are basically two ways how abstractions communicate with each
other: inlets and receives.
i'd propose that every inlet / outlet / receive declares a loadbang
function. before this loadbang function has been run, the outlet events
are queued (maybe using clock callbacks), then then the behaviour is the
same as currently.
for the outlets it's more tricky, since they'd have to register a
loadbang on the parent canvas.
if someone can think of a more elegant way / has a different opinion,
i'd like to hear ...
cheers ..... tim
--
mailto:TimBlechmann@gmx.de ICQ: 96771783
http://www.mokabar.tk
latest 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