hi all,
after thinking a bit about the recent discussion re: electric circuits in software, id like to share an idea and ask for help as well:
there is an fine, open-sourced circuit emulator available: http://ngspice.sourceforge.net/
my idea is to implement ngspice as a pd object, or, on the long run, as a set of objects representing the parts. for a start i think it would be sufficient to have a single object that loads a netlist. that netlist has to be generated in en external tool, preferably from the gEDA suite http://gnuwin.epfl.ch/apps/geda/
after that it would be great to split up the rather big ngspice package into serveral objects, and eventually integrating a way to use a pd patch as a netlist source for it. that way, a circuit could be drawn as kind of subpatch.
altough i have no idea yet about the performance, it should be possible to run simpler circuits like oscillators and filter in realtime pretty well. and i mean in a way that it can be used in a performance, and not just "runs, but takes 90% cpu" .... ;)
also i think that for the purpose of making it a pd object, some things could be simplified regarding the math to calculate the net's. any math-heads around that like to help with that? trading accuracy for speed, in this case.
what do you think? anyone like to participate in such a project? for me alone that would be bit to much right now, but i think it would be a nice thing to be able to emulate real synth/filter/etc. circuits in pd and mix that with the realtime audio capabilities ....
greets,
chris
It sounds like an awesome idea. I was recently chatting with Massimo Banzi, one of the Arduino creators, about the possibililty of creating a Pd-ish language for programming microcontrollers. This seems like it would be the perfect compliment to the idea. I forwarded this proposal to the Arduino crew to see if they are interested.
.hc
On May 6, 2006, at 6:48 PM, Christian Klippel wrote:
hi all,
after thinking a bit about the recent discussion re: electric circuits in software, id like to share an idea and ask for help as well:
there is an fine, open-sourced circuit emulator available: http://ngspice.sourceforge.net/
my idea is to implement ngspice as a pd object, or, on the long run, as a set of objects representing the parts. for a start i think it would be sufficient to have a single object that loads a netlist. that netlist has to be generated in en external tool, preferably from the gEDA suite http://gnuwin.epfl.ch/apps/geda/
after that it would be great to split up the rather big ngspice package into serveral objects, and eventually integrating a way to use a pd patch as a netlist source for it. that way, a circuit could be drawn as kind of subpatch.
altough i have no idea yet about the performance, it should be possible to run simpler circuits like oscillators and filter in realtime pretty well. and i mean in a way that it can be used in a performance, and not just "runs, but takes 90% cpu" .... ;)
also i think that for the purpose of making it a pd object, some things could be simplified regarding the math to calculate the net's. any math- heads around that like to help with that? trading accuracy for speed, in this case.
what do you think? anyone like to participate in such a project? for me alone that would be bit to much right now, but i think it would be a nice thing to be able to emulate real synth/filter/etc. circuits in pd and mix that with the realtime audio capabilities ....
greets,
chris
PD-ot mailing list PD-ot@iem.at http://lists.puredata.info/listinfo/pd-ot
________________________________________________________________________ ____
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
hi hans,
Am Sonntag, 7. Mai 2006 15:54 schrieb Hans-Christoph Steiner:
It sounds like an awesome idea. I was recently chatting with Massimo Banzi, one of the Arduino creators, about the possibililty of creating a Pd-ish language for programming microcontrollers. This seems like it would be the perfect compliment to the idea. I forwarded this proposal to the Arduino crew to see if they are interested.
hey, cool!
to me, stuff like spice on one side, and then things like pd on the other are very similar in the concept: they both take a netlist of parts/objects and then calculate the result of that. spice just makes nice curves/diagrams, pd sends the data straight to the audio device .... but essentially, i cant see much of a difference ...
thats why i think both would make a nice couple, especially for all the analog sound freaks out there ;) sure it is not use-able to emulate some full-featured, digital circuit with it... i dont see much sense in that anyway, since it could be done in pd natively, its just the sound generation/manipulation through circuit emulation that i am after ...
.hc
if that comes true, i will sit down for a whole month in a row and capture schematics of synth's and filter's into spice files .... i swear ... ;)
greets,
chris
On May 6, 2006, at 6:48 PM, Christian Klippel wrote:
hi all,
after thinking a bit about the recent discussion re: electric circuits in software, id like to share an idea and ask for help as well:
there is an fine, open-sourced circuit emulator available: http://ngspice.sourceforge.net/
my idea is to implement ngspice as a pd object, or, on the long run, as a set of objects representing the parts. for a start i think it would be sufficient to have a single object that loads a netlist. that netlist has to be generated in en external tool, preferably from the gEDA suite http://gnuwin.epfl.ch/apps/geda/
after that it would be great to split up the rather big ngspice package into serveral objects, and eventually integrating a way to use a pd patch as a netlist source for it. that way, a circuit could be drawn as kind of subpatch.
altough i have no idea yet about the performance, it should be possible to run simpler circuits like oscillators and filter in realtime pretty well. and i mean in a way that it can be used in a performance, and not just "runs, but takes 90% cpu" .... ;)
also i think that for the purpose of making it a pd object, some things could be simplified regarding the math to calculate the net's. any math- heads around that like to help with that? trading accuracy for speed, in this case.
what do you think? anyone like to participate in such a project? for me alone that would be bit to much right now, but i think it would be a nice thing to be able to emulate real synth/filter/etc. circuits in pd and mix that with the realtime audio capabilities ....
greets,
chris
PD-ot mailing list PD-ot@iem.at http://lists.puredata.info/listinfo/pd-ot
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
On Sun, 7 May 2006, Christian Klippel wrote:
thats why i think both would make a nice couple, especially for all the analog sound freaks out there ;) sure it is not use-able to emulate some full-featured, digital circuit with it... i dont see much sense in that anyway, since it could be done in pd natively, its just the sound generation/manipulation through circuit emulation that i am after ...
I think that if you're going to emulate analog electronics using Pd, you will have to create a new subsystem aside the messagesystem and the signalsystem, which will work sort of like the signalsystem but will take into account two-way interaction between components. Analog circuits don't have much to do with dataflow, it's just that most readymade components are made to approximate dataflow because it's a model that is easier to think about than something that needs you to solve linear equation systems just to find what anything is doing.
For those who'd rather face the analog electronics, this could be a really cool project. I'm curious how you'd implement the following in Pd:
.-[ohm 22]-.------------[ohm 15]-. | | | A ----| `-[ohm 33]-. |---- B | | | `-[ohm 47]-'----------'-[ohm 68]-'
such that if a [ohmmeter] gui object is plugged into A and B it will find the right voltage. I don't really know how existing algorithms work. Do you plan to use existing algorithms or come up with more efficient ones? What is the samplerate required at the analog-simulation level in order to be able to produce a pitch like [osc~ 11025] in a rather faithful way?
I didn't distinguish inlets and outlets in the above diagram. This is because a resistor doesn't distinguish between inlets and outlets. In your system, what would be considered an inlet and what would be considered an outlet and why?
I copied this to pd-list because I don't see anything off-topic in the idea...
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada