Hi Thomas!
Hi Davide, i'm starting to work with the clr external. Running the clr on OSX crashes PD for now, i'm trying to find the reason a bit later.
pland also reports this.. at work i have a G4 with osx 10.3 installed and the external performs well, no crashes no latency no startup time (as in winXP) etc...
Concerning the cvs, it would be great if you could also add the source for the PureData.dll which is now a kind of black box.
PureData.dll sources are in the pd folder.. maybe we should rename this folder to PureData so it would be more intuitive? that is here: http://cvs.sourceforge.net/viewcvs.py/pure-data/externals/clr/pd/
A thought a bit about the naming of functions for the Pd domain and also the external classes. I find it a bit too verbose. Are you sure that it's necessary to call it "DelegateWithoutArguments" or "PostMessage" when the functions are in their own namespace? It's really my personal taste, but i would prefer sticking closer to the naming of the original PD API functions (and i admit i don't like typing that much...)
yeah, me too, i was misleaded by visual studio auto-completition feature (I just need to write "pd." and I get all available functions...
I gave verbose names thinking that this maybe the clr external will be usefull to not experienced developers.. that was my first time using delegates and I guess fiew developers know them.. also i thought that maybe this external could help how is not comfortable with writing C externals so giving a more "user friendly" interface could be good..
but that is just my personal point of view, that is something I am happy to change if you think is better..
What i'm also wondering about is the
mixture of class and objects initialization in SetUp (wouldn't Main be a better choice, since that's already reserved in C#?). In the example externals, you are setting up both selectors (which is bound to the class) and inlets/outlets (which must be done during object construction). I guess SetUp/Main() should be static, so that it can be called on class initialization (e.g. in the loader) independently from an object instance, and then, the object initialization (like AddInlet etc.) should be done in the object constructor.
Ok, I must admit that in my mind wasn't clear enough the external.setup() vs external.new() distinction.. now it is becoming a bit more clear, but i must admin, not enough...
anyway the SetUp() name could lead to misunderstanding: the clr external doesn't really register those selectors! actually it registers only 4 methods:
- one for bangs
- one for floats
- one for symbols
- one for lists
when you call AddSelector the clr instance simply stores that string in an array together with a MonoMethod (which will be called when this selector is the first atom of an incoming list). So the selectors registration is not performed at class initialization but at object initialization.
really it may be better to use just another name than SetUp.. maybe just the C# class constructor?
I don't completely understand the usage of namespaces in the CLI, but is it really necessary to put the client externals into the PureData namespace?
.. now that i think better.. i don't think is necessary for externals to be in the PureData namespace
It's also a bit misleading that
the Pd functions are in the Pd class, but a PureData.dll is needed for using them.
yes, that's weird, but i didn't find a way to have functions outside a class, so I was forced to create a static class for them.
I'm really looking forward to working with the clr external!
hey, let's rock!
best greetings, Thomas
Am 17.01.2006 um 23:20 schrieb Davide Morelli:
well, not yet.. I mean i've asked Thomas how to use it and he kindly
explained me but
I haven't had time yet to write that code.. I'd surely need more info from him.. and a bit of time to
recompile pd
with his patch, read the source code, understand how it works and modify my external.. this way sounds complicated but that is not tru, should be simple
...maybe the better thing would be that he modify clr
directly on CVS?
or write a very very simple how-to?
davide.
-----Messaggio originale----- Da: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at]
Per conto
di Hans-Christoph Steiner Inviato: martedì 17 gennaio 2006 20.57 A: pd-list@iem.kug.ac.at Oggetto: [PD] Re: [PD-announce] clr: externals in CLR assemblies
This is great. I am assuming that you are using the new loader functionality from Thomas. Would it be possible if you
could put up
some notes about what you did? It'll help others like me
write other
loaders.
.hc
On Jan 17, 2006, at 11:07 AM, Davide Morelli wrote:
hello!
[clr] is an external that lets you create externals using clr languages (C#, vb.net, ruby.net, dotLisp, etc..), it embeds mono.
you can find it in /externals/clr
At the moment it can only receive and send bangs, floats,
symbols and
lists. ASAP I'll add support for pointers, signals and Gem.
Also many
important functions are not present (things like timer callbacks etc..)
I've tested it on winXp and osx 10.3 but i'm pretty sure it
will work
on linux too. I need help writing makefiles, defining dependancies and testing. I will soon build binary packages. It is possible to build binary packages including mono and
all the GAC
so the "end-user" won't need to install mono to use [clr] and the externals needing it
requirements:
- mono installed
- glib, gthread, iconv in path (they should be inside
mono as well)
what you need to do to compile it:
- edit PATHs in the makefile so the compiler can find
mono, glib,
gthread, etc...
to write an external you need to:
- in the pd folder compile pd.cs and Atom.cs into PureData.dll
- use the PureData namespace
- add PureData.dll to the references
- declare an "private intPtr x" variable
- declare a "void SetUp()" function and put there inlet,
outlet and
selectors creation (see the external folder for a couple of
examples)
features:
- you can write externals in any clr language (C#, managed
C++, J#,
Jscript.Net, PerlNET, Ruby, Scheme, VB.NET, dotLisp and a
lot more.. )
- use bangs, symbols, lists (both in and out)
- declare inlets, outlets, selectors
- use initialization arguments
- multi-instance
- compile many externals into one single .dll file
- extend an external including its assembly instead of
modifying its
source code
- you can compile the external using whichever clr
compiler you like
most
- assemblies are "cross-platform" (a single .dll file for all
platforms)
what is missing:
- support for signals, Gem, graphical externals
- many callback functions like timers etc..
- there may be threading issues
- testing, testing, testing!
detailed implementation notes, (future) binary pakages here: http://www.davidemorelli.it/dokuwiki/doku.php?id=csharp:csharp
PS. many thanks to Thomas Grill for his help!
Ciao, Davide Morelli www.davidemorelli.it
PD-announce mailing list PD-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
Man has survived hitherto because he was too ignorant to
know how to
realize his wishes. Now that he can realize them, he must either change them,
or perish.
-William Carlos Williams
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list