Frank Barknecht wrote:
I managed to finish my first extension (even while I haven't got a clue what pd is up to:-)).
We call these things "externals" around here. ;)
I told you I was a newbie :-)
It doesn't seem to do this all the time. With some wild clicking on attached patch I can make it send a "0" to the first inlet as well, although no note 0 was ever sent. If it's in that state, also no velocity output is generate anymore.
Hmmm. It seems it got confused when receiving a noteon for a note that was already on (so without the acompanying noteoff inbetween), something that's quite difficult to pull off with a midi keyboard. I think it handles it a little bit smarter now. Could you please run your test again, as I'm not exactly sure if I'm just lucky here?
One thing that IMO should accompany every Pd external is a help patch. Just make a file NAMEOFEXTERNAL-help.pd (legato-help.pd) that shows and explains what your object does, what the inlets accept and what the outlets will produce. Ideally you'd make a little example of the object in use as well. help-patches are a good way to test objects as well.
Ok, I changed your's a bit. Is that sufficient? Would one normally keep all documentation in the .pd file, or is a README.txt sometimes used?
I didn't need to edit the Makefile at all on Linux, however I did change #include "m_pd.h" to #include <m_pd.h> (see another thread here). If m_pd.h is in a system include path, all the PDROOT stuff is unnecessary to build the class.
Ok, changed it to #include <m_pd.h> in makefile
- It doesn't like to receive a bang <snip>
That's okay: If an object is not supposed to deal with "bang" than that's how that object is supposed to be and printing the error/warning to the console is fine.
Ok
- Should I put it up somewhere, for instance on my servers svn-repo?
puredata.info would be a good place as well. Or I would volunteer to add it to the Sourceforge-CVS.
For now it's here (the "s" at the end, is a sign of optimism): svn co svn://atte.dk/attes-pd-externals