This is intended all right, but on the other hand, perhaps it isn't the right idea in teh first place... is it more useful to have loadbang always called?

The only example I know of is the "loadbang" object, for which it makes no sense to have it emit a "bang" before you connect it to anything...!

Actions to be taken on object creation can be put in the "new" routine. However, perhaps there are examples of actions that should be taken for all new objects, but, if it's being restored from a file, should only happen once the object is fully connected and the rest of the patch is intact. I can't think of any examples of that offhand...

cheers Miller

On Fri, Feb 22, 2002 at 08:45:53AM +0100, Thomas Grill wrote:

Hi Miller,

...

I'm not sure how Max does it; in Pd you just declare a "loadbang" message and it gets banged (for you to do whatever with.)

yes, loadbang gets triggered when the object's patch is loaded, but it doesn't (in PD) when an object is newly created within an existing patch. Is this intended behavior?

greetings, Thomas

Hmm, ".._new()" is only called when an object is instantiated. If you save, close, then re-open a patch, the new() routine has to get called again fo rthe new instantiation, but as long as you keep the patch open, you should be able to save it all you wish.

There is a problem in that Pd doesn't warn objects properly when they're getting freed... the free() routine gets called right before the object is destroyed adn you don't have a chance to open a save() dialog if you want to save internal state separately. I want to fix that for a future release.

cheers Miller

On Fri, Feb 22, 2002 at 05:42:42PM +0100, Frank Barknecht wrote:

Miller Puckette hat gesagt: // Miller Puckette wrote:

...

Actions to be taken on object creation can be put in the "new" routine. However, perhaps there are examples of actions that should be taken for all new objects, but, if it's being restored from a file, should only happen once the object is fully connected and the rest of the patch is intact.

I have a question regarding this: At which times is the new-routine called? I'm asking, because in my rx7~ external, I can load a sound bank with a "load" message. If I then save the whole patch, the loaded bank disapears and has to be loaded again. I suspect, that "..._new" is called again, when the patch gets saved. Is this correct?

If yes, I'll have to take precautions to keep the bank alive...

bye,

                                             __    __

Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______ / __// __ /__/ __// // __ \ / / __ \ ___\ / / / ____/ / / / // ____// /\ \ ___\____ \ /_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\

Hi Olaf and all,

Yes, DSP and "event" computations have the same priority, and the order in which they are carried out is deterministic (so that DSP doesn't interrupt event processing, for example.) There's only one thread, although nothing stops objects from sprouting their own threads. (but don't call outlet_...() except from the "main" thread!)

Ther's something else wrong with your setup if long computations cause audio to die or Pd to crash. You should be able to call "sleep(5)" from an object and have Pd bounce back after 5 seconds as if nothing were wrong except a DIO error. If this isn't working it's wrong and I'd like to know what audio hardware&drivers you're getting this with...

Sorry, I'm not sure windows has a "sleep" function, substiture a for loop counting to 1000000000 for example.)

cheers Miller

On Fri, Feb 22, 2002 at 07:17:43PM +0100, Olaf Matthes wrote:

Hi Miller, hi all,

I've a question concerning the 'timing' of pd. I once had difficulties to load several soundfiles into arrays using loadbang. Pd reported "audio I/O stuck..." and crashed. A workaround was to delay the loadbang by several ms each before loading the next soundfile. Now I have problems with my oggcast~/oggamp~ externals when connecting to the server via the net. Using a "connect" message sort of stops pd, i.e. audio out stops and goes on after the connection has been established. But sometimes pd crashes reporting the same "audio I/O stuck..." as last message... My question now is if this is due to the architecture of Pd and if there are any ways to avoid it. I allways thought only the perform routine to be time critical but now I begin to realise that everything has to fit inbetween two dsp calls. Is this right? If yes, is there no multithreading inside Pd (in the windows version) to have non-signal routines running in a second thread? (my externals use multithreading just for encoding / decoding and data transmission via TCP since this would halt the performe routine)

Olaf

Miller Puckette schrieb:

...

There is a problem in that Pd doesn't warn objects properly when they're getting freed... the free() routine gets called right before the object is destroyed adn you don't have a chance to open a save() dialog if you want to save internal state separately. I want to fix that for a future release.

cheers Miller

The only example I know of is the "loadbang" object, for which it makes no sense to have it emit a "bang" before you connect it to anything...!

Actions to be taken on object creation can be put in the "new" routine. However, perhaps there are examples of actions that should be taken for all new objects, but, if it's being restored from a file, should only happen once the object is fully connected and the rest of the patch is intact. I can't think of any examples of that offhand...

Is it the case that in PD all arrays are readily accessible at the creation of the other objects? I never problems with this, but i'd like to be sure that i wasn't just lucky....

In Max/MSP i always have to use loadbang instead of the new routine when using a buffer~ (same as an array in pd) as an argument to an object. They seem to have no special treatment there and are created just in time with the other objects of a patcher.

thanks, Thomas

flext, xsample etc. http://www.parasitaere-kapazitaeten.net/Pd/ext

hi Thomas,

it is generally better to get into the arrays when they are needed, like in a <class>_dsp() method, not in a constructor. Usually you would only store an array name in <class>_new().

There might be a case, when an array should be written to by an external object right away after the patch is loaded. If so, there are two ways: a) requiring of users to explicitly connect a [loadbang] object to an external object, or b) calling clock_new(<init-routine>) and clock_delay(<clock>, 0) in a <class>_new() routine, then clock_free(<clock>) in a <class>_free().

And no -- objects and arrays are created in one pass, in the same order they happen to have their defining lines in a .pd file. Those lines (#X obj..., #X array...) are simply ``create this or that'' requests to a current canvas object.

Krzysztof

Thomas Grill wrote: ...

Is it the case that in PD all arrays are readily accessible at the creation of the other objects? I never problems with this, but i'd like to be sure that i wasn't just lucky....

In Max/MSP i always have to use loadbang instead of the new routine when using a buffer~ (same as an array in pd) as an argument to an object. They seem to have no special treatment there and are created just in time with the other objects of a patcher.

hi Thomas,

unless a message is delayed explicitly via a clock, there is no point in self-messaging, because sending a message in Pd is implemented as an immediate call of a method (there is no message queue).

Another way is to schedule triggering of the sub-methods in a method registered in the dsp chain. This only applies to certain actions of tilde objects -- a nice example is sfplay~ external (from ggee or zexy).

Krzysztof

Thomas Grill wrote: ...

...

object to an external object, or b) calling clock_new(<init-routine>) and clock_delay(<clock>, 0) in a <class>_new() routine, then clock_free(<clock>) in a <class>_free().

are there another ways of self messaging? In other words, is there a way to send a message from within an external to its own inlet?

Self-retriggering (and dividing longer operations into smaller chunks) would often be helpful and eliminate the need for a second thread.

On Fri, 22 Feb 2002, jsf103 wrote:

Sorry to add yet another tedious and over asked question to this mailing list but I really need some help. I am trying to write some pd externals and decided to start by using the tutorial example "Helloworld". BUT Visual C++ WILL NOT compile it, it simply says 'UNEXPECTED END OF FILE WHILE LOOKING FOR PRECOMPILED HEADER DIRECTIVE". I really don't know what to do, and yes I have looked through the archives and still found nothing. I just need to know how to set up Visual C++ for pd. PLEASE help me someone!!

(Mark already answered to this one) if you still have problems try getting a pd-library (for windows) that already has a vc-workspace (*.dsw) pe: zexy, iemlib

delete the source-files in your project-manager window and insert yours. and maybe you will have to edit the project-properties to export helloworld_setup instead of orglib_setup (pe: zexy_setup) i don't know right now because there is no vc right at hand.

if you want to create your own workspace be sure to insert the correct source-paths to the pd-includes (to find m_pd.h which is in pd/src) and the linker-paths to the pd-libs (pd.lib which is in pd/bin) nevertheless, you might have to edit these paths even if you use already existing workspaces to match your installation.

mfg.cdas.r IOhannes

ps: gosh, it is really time to add a "compiling??"-section to the HOWTO. please, can anyone send me instructions for alternative windows-compilers (cygwin, borland-builder,...) since i have none of these

Right clicking on project name and selecting 'Add Files To Project' from context menu will open a file dialog box to enable existing source files to be added in to the project workspace.

John Heenan

----- Original Message ----- From: "John Heenan" john@auscyber.com To: "pd-list" pd-list@iem.kug.ac.at Sent: Sunday, February 24, 2002 9:41 PM Subject: Re: [PD] Compiling PD externals

I have little problems with the following approach to using makefile based projects within the MS Visual C++ IDE. In fact it makes project management very convenient.

1. Ensure you have a working makefile for a project (such as a skeleton

project) that works from the command line. 2. Open the makefile as a workspace in MS Visual C++ (File, Open Workspace). Specify files of Type 'makefile' with File name '*' to ensure makefiles without extensions can be chosen (as occurs in PD). You can compile your project as is without any sourcefiles visible in the project workspace 3. Add in source files to the project workspace as appropriate.