Hi,
I am working on a component that will end up as a PD external and
I am needing a hashmap or something similar - poking around I discover
the Standard Template Library which looks like it has what I need (which
makes me feel old - this has appeared since I stopped using C++ afer
using it
for years and years - eek!)
Anyway - my questions is - if I use this (I am using Visual C++ .Net at
the moment )
will my stuff compile on all of the other non-windows platforms you guys
are using?
…
[View More]I assume that STL is ok and not a pile of garbage that everyone avoids
like the
plague.
cheers
mark
[View Less]
Hi list,
just another developers announcement. I've put some new stuff on my
'experimental' site at
http://www.akustische-kunst.org/puredata/experimental/
shoutcast~ version 0.3 :: threaded version of the mp3 streamer, now also
supports variable bitrate encoding (VBR). I've tested it for quite a
while but it still seems to crash under rare circumstances (after about
2 hours or so...)
netserver / netclient :: server/client externals that allow for
bidirectional communication. they both are a …
[View More]combination of Pd's netsend
and netreceive objects. Additionally the server (based on netreceive)
can send data back to the client (which is based on netsend). The client
to send to can be selected using a 'client number' or the socket number
of the connection. I'll probably include them into maxlib one day.
Everything is 'experimental', so beware the bugs! In case you discover
any problems, please send me a bug report / call for help!
Olaf
[View Less]
hi all,
as I have spent all day cleaning and backing up the stuff before
going for a longer break, I thought I would try to release an
experimental, stripped-down version of the ever-vapory `vexing'
library. It is called just 'vex', and is somewhat explained at
http://suita.chopin.edu.pl/~czaja/miXed/externs/vex.html
Feel free to use any part of it in any form and in any way.
Keep patching,
Krzysztof
p.s. this is sent to the PD-dev, not PD-announce, on purpose...
Hi there,
I have put pd version 0.35 under CVS on sourceforge, in order to be
able to track patches against pd itself.
Currently I have included Stefans jack patch, Rainers jack patch and
the GUI patches from Joseph. (Really nice and simple solution !)
There is one branch where you can access the patched source (called
devel_0_35).
Check it out:
cvs -d:pserver:anonymous@cvs.sf.net/cvsroot/pure-data login
Hit return for password.
cvs -d:pserver:anonymous@cvs.sf.net/cvsroot/pure-data co -r …
[View More]devel_0_35 pd
for getting the source.
Other branches are:
jack_0_35_0_cb .. for the callback based jack implementation
jack_0_35_0_fifo .. for the fifo based jack implementation
I couldnt handle the ~ directories in the extra folder, because CVS
thinks they are backup files. Have to investigate.
Greetings,
Guenter
[View Less]
Hi all,
I seem to be getting some very ugly segfaults from strange interactions
between my chaos math externals (lorenz, henon, rossler).
Each external works perfectly on thier own, but if I put more than one in
a patch, or changle the name of one to another in an object box I get
strange values output (like + or nan) , or segfaults.
I'm just sending the henon external, the other two work just the same but
with different equations.
Here is my Source:
------------------
#include "m_pd.…
[View More]h"
#include <math.h>
#include <stdlib.h>
t_class *myclass;
typedef struct thisismystruct
{
t_object myobj;
double a,b,lx0,ly0;
t_outlet *y_outlet;
} mystruct;
void calculate(mystruct *x)
{
double lx0,ly0,lx1,ly1;
double a,b;
a = x->a;
b = x->b;
lx0 = x->lx0;
ly0 = x->ly0;
lx1 = (ly0 + 1) - (a * pow(lx0,2));
ly1 = b * lx0;
x->lx0 = lx1;
x->ly0 = ly1;
outlet_float(x->myobj.ob_outlet, (t_float)lx1);
outlet_float(x->y_outlet, (t_float)ly1);
}
void reset(mystruct *x, t_floatarg a, t_floatarg b)
{
x->a = (double)a;
x->b = (double)b;
x->lx0 = 1;
x->ly0 = 1;
}
void *henon_new(void)
{
mystruct *x = (mystruct *)pd_new(myclass);
x->a = 1.4;
x->b = 0.3;
x->lx0 = 1;
x->ly0 = 1;
outlet_new(&x->myobj, &s_float); /* Default float
outlet */
x->y_outlet = outlet_new(&x->myobj, &s_float);
return (void *)x;
}
void henon_setup(void)
{
myclass = class_new(gensym("henon"), /* symname is the
symbolic name */
(t_newmethod)henon_new, /* Constructor Function */
0, /* Destructor
Function */
sizeof(mystruct), /* Size of the
structure */
CLASS_DEFAULT, /* Graphical
Representation */
0); /* 0 Terminates
Argument List */
class_addbang(myclass, (t_method)calculate);
class_addmethod(myclass,B
(t_method)reset,
gensym("reset"),
A_DEFFLOAT,
A_DEFFLOAT,
0);
}
Here is my GDB Output:
----------------------
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 5262)]
0x0808a0d7 in outlet_float (x=0x80e04e0, f=-0) at m_obj.c:343
343 pd_float(oc->oc_to, f);
(gdb) where
#0 0x0808a0d7 in outlet_float (x=0x80e04e0, f=-0) at m_obj.c:343
#1 0x400175a0 in calculate () from
/usr/local/lib/pd/extra/rossler.pd_linux
#2 0x0808a007 in outlet_bang (x=0x80e0288) at m_obj.c:311
#3 0x08072473 in bng_bout2 (x=0x80e01b8) at g_7_guis.c:1211
#4 0x08072681 in bng_click (x=0x80e01b8, xpos=184, ypos=115, shift=0,
ctrl=0,
alt=0) at g_7_guis.c:1254
#5 0x080726ce in bng_newclick (z=0x80e01b8, glist=0x80dfc00, xpix=184,
ypix=115,
shift=0, alt=0, dbl=0, doit=1) at g_7_guis.c:1260
#6 0x0806a54d in gobj_click (x=0x80e01b8, glist=0x80dfc00, xpix=184,
ypix=115,
shift=0, alt=0, dbl=0, doit=1) at g_editor.c:62
#7 0x0806b5e9 in canvas_doclick (x=0x80dfc00, xpos=184, ypos=115,
which=1, mod=0,
doit=1) at g_editor.c:455
#8 0x0806bd84 in canvas_mousedown (x=0x80dfc00, xpos=184, ypos=115,
which=1, mod=0)
at g_editor.c:606
#9 0x08089012 in pd_typedmess (x=0x80dfc00, s=0x80d41d0, argc=0,
argv=0x80cb308)
at m_class.c:669
#10 0x080681c7 in guiconnect_anything (x=0x80dfad8, s=0x80d41d0, ac=4,
av=0x80cb2e8)
at g_guiconnect.c:70
#11 0x08089218 in pd_typedmess (x=0x80dfad8, s=0x80d41d0, argc=4,
argv=0x80cb2e8)
at m_class.c:690
#12 0x0808c984 in binbuf_eval (x=0x80de808, target=0x80dfad8, argc=0,
argv=0x0)
at m_binbuf.c:570
#13 0x08091ca4 in socketreceiver_read (x=0x80de828, fd=8) at s_inter.c:307
#14 0x0809164a in sys_domicrosleep (microsec=0, pollem=1) at s_inter.c:144
#15 0x08092815 in sys_pollgui () at s_inter.c:732
#16 0x0808fee6 in m_scheduler (nodacs=0) at m_sched.c:441
#17 0x080904f9 in sys_main (argc=1, argv=0xbffff7e4) at s_main.c:258
#18 0x08094356 in main (argc=1, argv=0xbffff7e4) at s_entry.c:9
#19 0x4007a9ed in __libc_start_main () from /lib/libc.so.6
Thanks for your help, I would appriciate any help/pointers anyone would
provide.
Thanks
Ben
B. Bogart
---------
[View Less]
Hi Miller, hi Stefan and dev-list,
Looking at the two jack implementations of pd at hand, I gave the
whole topic another thought, and I think that pd needs a separate
scheduler in order to serve as a plugin.
I am trying to outline why Stefans solution is much better than the
FIFO solution, and actually, the good thing is that we should be
able to use the same approach to make pd plugable as VST plugin.
1) Latency
The FIFO solution will always introduce one block of latency (as defined
by …
[View More]the callback API, so this block will be larger than the 64 samples pd
uses).
e.g. just to copy the input to output, the FIFO guards the input
in the callback (be it jack, VST or anything else), and at the same
time writes the result of the calculation from the last block.
Whereas the correct solution would be to get the
input -> process it -> write the output.
There is a way around this by synchronizing via locks, though,
but handling getting rid of locks and doing the processing in
the loop directly seems to be a clearer solution.
2) A bigger problem is timing.
Currently pd implements its timing with 64 sample resolution, there is no
way to calculate several of these blocks faster than realtime, because
the sys_microsleep keeps the processing loop synced to real time.
This is good, because MIDI timing for example depends on this.
For a callback solution we cannot stay in realtime, we have to be faster
in order to give other plugins a chance to do their processing, so the
microsleep has to be thrown out.
This, in turn will destroy MIDI timing.
One thinkable solution to keep the timing correct is a new thread that
buffers realtime events, it should buffer and timetag them, this way,
of course latency for realtime events will be increased.
Note that this problem persist for both, the locked FIFO and the
processing in the callback.
3) I do not fully understand why the "non realtime capable" operations
such as patch loading, array loading, are worse than before when
using Stefans implementation of the jack API. To me it seems that they
should have exactly the same impact as they already have.
Stefan, do you have an idea why this might not be the case ?
Sorry for the length of the message
Greetings
Guenter
[View Less]
Hello,
I'm just trying to get a pd external to work with a binary windows release of
pd. I compiled my external with MSVC++ 6.0 and I'm loading the lib using the
following command when starting pd:
pd -nomidiin -path d:\pd-patches -lib d:PDLIB\source_tilde
pd is printing the following error message:
load_object: Symbol "source_tilde_setup" not found
D:/PDLIB/source_tilde: can't load library
pd is definitely finding the .dll file and there's also a source_tilde_setup
function compiled …
[View More]into the library. I guess that my problem has something to
do with C++ -> C - functions in dlls so I tried using the "disable language
extensions" switch of MSVC++ in order to get ANSI C but this seemed to have
no effect.
Does anyone know how I could get rid of this problem?
Thanks in advance,
Phil.
[View Less]
Hi Reiner, dev-list,
I have updated Reiner Klenk's jack patch for pd to apply to the new
test version. Find it at
ftp://xdv.org/pub/gige/pd/
The patch implements the FIFO solution (so its not the solution suggested
by the jack authors), but considering pd's scheduler loop it fits pretty
well.
I have just added the DIO error blinking and renamed some global variables
to start with jack_. The latency and buffering might need some tweaking
(made it smaller for testing on the edge).
configure …
[View More]--enable-jack
pd -jack
Guenter
PS: (Dont be surprised if you get a similar message soon, which is
awaiting the moderator at the IEM because it includes the patch)
[View Less]
Thanks Miller,
I did not explian my problem concisely. I have a PD external (in C) which
has a struct which contains the starting condisions of the system. These
variables are set in the lorenz_new method. Then each invocation of the
"lorenz" method actually calculates one interation of the algorithm. My
problem is that when I have more than one object the construction of the
second instance of the object reset the conditions of *both* instances.
How do give two instances of the same PD …
[View More]external different data-spaces?
I'll send my ocde if I'm not being clear enough.
Thanks
Ben
On Sat, 20 Jul 2002, Miller Puckette wrote:
> Hi Ben,
>
> Just back from vacation, trying to get back in the swing now...
>
> Are you having trouble because "sends" and "receives" are talking between the
> instances or something like that? If so, use "send $0-your-name-here" and
> it will expand to a private name for each instance. (table, value, and other
> things that use names should all work the same way...)
>
> cheers
> Miller
>
> On Sat, Jul 20, 2002 at 09:58:24PM -0400, Ben Bogart - FMPM/F1999 wrote:
> > Thanks Miller,
> >
> > While I'm thanking you I might as well ask a question. I've just
> > implemented the "lorenz attractor" as a PD external, but I seem to only
> > be able to have one instance of it, they interfere with one and other. Is
> > the struct (dataspace) of an external shared across instances? If so how
> > can I make a seperate dataspace for each instance?
> >
> > I'm teaching a little PD workshop at Interaccess (www.interaccess.org) in
> > about a months time. Hoping to convert a few of those MAX users. ;)
> >
> > Hope your vacation is going well (if you still on it?)
> >
> > Ben
> >
> > On Sat, 20 Jul 2002, Miller Puckette wrote:
> >
> > > Wow, spiffy
> > >
> > > cheers
> > > Miller
> > >
> > > On Wed, Jul 10, 2002 at 01:51:30PM -0400, Ben Bogart - FMPM/F1999 wrote:
> > > > www.dcn.ryerson.ca/~bbogart/pollock.jpg
> > > >
> > > > Special thanks to Jamie for the OSX port!
> > > >
> > > > Ben
> > > >
> > > >
> > > >
> > > > B. Bogart
> > > > ---------
> > > >
> > >
> >
> >
> >
> > B. Bogart
> > ---------
> >
> >
> >
> > _______________________________________________
> > PD-dev mailing list
> > PD-dev(a)iem.kug.ac.at
> > http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
>
B. Bogart
---------
[View Less]
Thanks Miller,
While I'm thanking you I might as well ask a question. I've just
implemented the "lorenz attractor" as a PD external, but I seem to only
be able to have one instance of it, they interfere with one and other. Is
the struct (dataspace) of an external shared across instances? If so how
can I make a seperate dataspace for each instance?
I'm teaching a little PD workshop at Interaccess (www.interaccess.org) in
about a months time. Hoping to convert a few of those MAX users. ;)
…
[View More]
Hope your vacation is going well (if you still on it?)
Ben
On Sat, 20 Jul 2002, Miller Puckette wrote:
> Wow, spiffy
>
> cheers
> Miller
>
> On Wed, Jul 10, 2002 at 01:51:30PM -0400, Ben Bogart - FMPM/F1999 wrote:
> > www.dcn.ryerson.ca/~bbogart/pollock.jpg
> >
> > Special thanks to Jamie for the OSX port!
> >
> > Ben
> >
> >
> >
> > B. Bogart
> > ---------
> >
>
B. Bogart
---------
[View Less]