Lets say I have a simple 2 operator FM synth using [osc~] objects. As long as the peak amplitude of the modulating oscilator remains below the Nyquist frequency ( I typically run at 48kHz, so this would be 24kHz), there should be no aliasing. Is this correct? or am i missing something.

I downloaded the latest version of Pd, I un-tarred and moved the directory to /usr/local/src. So far so good. Then I cd into the ../pd/src directory (as indicated in the readme) and type ./configre. All I get is the response bash: file not found. When I checked the contents of the directory there are two files; configure.in, and config.h.in neither of which is the configure script. So, I downloaded the previous version (Pd-0.40.3-extended), and tried again. Same problem. so now I am wondering, is this a problem with the packages I've downloaded or is there something amis with my system? ie should I have a generic configure script installed in /usr/bin? can I copy and paste any old configure script from another software package? Any thoughts and opinions will be appreciated.

FWIW I am running Debian Lenny w/ RT kernel. x86 architecture....

P.S. the reason I am compiling is because I can't get the extended version w/ apt-get, and when I try to install the debian package manually (w/ dpkg) the package list gets confused over a broken dependency.

This code, IOhannes m zmoelnig 2001-09-13, if I am correct, defines a structure of type " _helloworld " and declares an instance of that structure called t_helloworld.

typedef struct _helloworld {
t_object x_obj;
} t_helloworld;

This is where I get confused. The code below defines a function which has one argument, the variable " x " which is declared as a pointer to type t_helloworld.

void helloworld_bang(t_helloworld *x)
{
post("Hello world !!");
}

How is this possible, if t_helloworld is a structure and not a type? Shouldn't the argument be "...(_helloworld *x)"?
I looked at the example code that comes with puredata, and it follows the exact same format. I compiled the examples and they seem to work fine, so I believe that the code is correct; I just don't understand why.

These code snippets came from IOhannes m Zmoeling's awsome guide to writing externals which can be found here:

http://pdstatic.iem.at/externals-HOWTO/node1.html

Hi, I am interested in building a patch manager/Editor in PD.
I recently bought a DX7, and I was wondering if any PD users out
there were experienced with the instrument. I know that the
[ctlin] and [ctlout] objects work for sending and receiving
controller data, but I think that loading and storing DX7 patch
parameters depends on sysex dumps. Is there a an object
that handles this. Also the DX7 I bought did not come with a manual,
so I was hoping someone might know how the parameters
are designated within the synth itself, or where I could find the
information. Thanks for any advice. I'll post the patch when it is completed,
which will have a virtual DX7 integrated into it.

What is a "dirty 0" message ?

>> > this bug was fixed with sending a |dirty 0( to the canvas

neat trick with the message box, I never knew that!

Awsome, thanks!

I am not exactly sure what the original intention of ths patch was, but it makes some awsome sounds!! gonna build a metalic noize-box out of it!!!

The scons build system? I will give that a shot. thanks for the suggestion!

You create inlets within your subpatch; one for each parameter Attack, Decay, etc... Then in the parent window you attatch message boxes to each inlet, that contain the initial values you want for each parameter. Then, you create a [loadbang] object, and connect its outlet to each of the message boxes.

The [loadbang] object outputs a bang when a patch is loaded, this bang tells the message boxes to send their values to your adsr subpatch.

So in the example which I posted;

typedef struct _helloworld {
t_object x_obj;
} t_helloworld;

the last line defines "t_helloworld" as a shorthand for "struct _helloworld" when declaring variables. Thank you very much Claudius for explaining this; I am a lot less confused when I look at the code!!!

Thanks for the info, I think it is the 2.22.6-14 kernel, with Ingo molnar's realtime preemption patch, -VP-2.6.9-rc4-mm1-U0. At least is what it says on the Ubuntu website. I'll try giving my username realtime priority, and see if that makes a difference. Will definately post whatever steps lead to a successful result.

This is the uncommented contents of my limits.conf file:

@audio - rtprio 99
@audio - memlock 512000

I am curious; @audio, I presume is a group. given that my kernel is supposed to be a realtime kernel geared towards audio and video, I am assuming that a realtime priority (rtprio ?) of 99 is the highest possible priority. Forgive my ignorance, but all of this stuff is kind of new to me.

School work has prevented me from further experimentation (it is very easy to lose hours troubleshooting as I am sure you have experienced . I'll probably be messing around with this more, a little later in the week. In the mean time, I am gonna test out the pure:dyne operating system; It is designed around PD, and boots from a live CD.

I did a little digging, There are a few startup flags which I am going to experiment with, that set PD's buffer size, and block size. My guess is that Pd's settings should match those of Jack, the problem is I have no idea how to set that up, This is copied straight from the Pd help file; the complete list can be found by entering " pd -help " into the terminal.

-audiobuf <n> -- specify size of audio buffer in msec
-blocksize <n> -- specify audio I/O block size in sample frames

Jack's buffer arguments are:
Frames/period, which are in powers of 2, ie 16, 32, 64, .... 4096
and periods/ buffer.

I have no idea how these parameters translate to PD's, but I am going to try experimenting with different settings.

addendum: running Pd with the -nrt (no realtime) flag I observed a minimal decrease in the rate of error appearances.

Tried increasing the buffer size, but I couldn't go higher than 1024 per period without jack crashing. I doubled the number of frames per period, 8 is the highest I can go without jack hanging up. And I'm still getting A/D/A sync errors every couple of milliseconds. Jack runs fine for me, I get 0 XRUNS at much lower latency settings. All of the DIO errors are on the PD side. I do have GEM, Zexy, and all four iemlibs loaded; could that be slowing things down? I have also tried running both PD and Jack as root, but that didn't help. The errors appear even without a patch open, and the CPU load is never greater than 4%. I am using PD 40-2, vanilla, which came packaged with ubuntustudio. I have built and installed all externals manually. Sorry this is so long winded, I appreciate your help

Bump...

I am having the same problem. When I send audio out from PD using Jack, I get approx. 3 to 6 DIO errors per second; all A/D/A sync errors. Needless to say, the audio comes out sounding like clipped garbage. There is no problem using ALSA directly, but doing so means that only PD gets to use the sound card. If anyone else has some experience with this, I'd really appreciate the advice.

Running ubuntustudio 7.10 (gutsy)
with Gnome 2.20.1 / Linux Kernel 2.6.22-14-rt (real time )

I checked out jsynthlib; my usb/midi interface should be here (hopefully by friday!!!). In the mean time I am gonna try and get it running.

It turns out, that [sysexin] is a vanilla-built-in object; which could prove usefull. however there is no built-in for sending sysex messages out. It looks like [comport] might be the way to go for this project, but it didn't come with my distro. I am gonna try and find it. and see if it works, maybe with my usb mouse.

Thanks for the Info; I'll certainly post more as I make progress.