Hello List, Chuck,
While browsing the pd-extended distro I found 2 other patches (than the comport.dll external) which allow us to take control of a serial port
serial Which seems to be windows only (it doen't seem there is a doc for this one) serialctl Which seems to be UNIX only
BTW Chuck, did you manage to do something with the comport.dll I sent to you?
Renaud
**** DISCLAIMER **** http://www.belgacom.be/maildisclaimer
Those are old and defunct. [comport] is the only maintained one, and
it works well. There have been a number of important changes in the
last few months, so use a current version.
.hc
On Nov 16, 2006, at 10:20 AM, renaud.herne@belgacom.be
renaud.herne@belgacom.be wrote:
Hello List, Chuck,
While browsing the pd-extended distro I found 2 other patches (than
the comport.dll external) which allow us to take control of a serial portserial Which seems to be windows only (it doen't seem there is a doc for this one) serialctl Which seems to be UNIX only
BTW Chuck, did you manage to do something with the comport.dll I
sent to you?Renaud
**** DISCLAIMER **** http://www.belgacom.be/maildisclaimer
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
¡El pueblo unido jamás será vencido!
Interesting. I did get the comport.dll to work, thanks. My plan was to send PWM from my serial port, then use a low pass filter to obtain DC to control a Moog synthesizer's pitch. Christian Klippel, however, has kindly offered to create a USB->CV adaptor for me, something others have suggested but which has proven too confusing for me. I suspected that MSVC was not free. I wonder how hard it would be to adapt the makefile to MinGW? Thanks very much for sharing the .dll!
-Chuckk
On 11/16/06, renaud.herne@belgacom.be renaud.herne@belgacom.be wrote:
Hello List, Chuck,
While browsing the pd-extended distro I found 2 other patches (than the comport.dll external) which allow us to take control of a serial port
serial Which seems to be windows only (it doen't seem there is a doc for this one) serialctl Which seems to be UNIX only
BTW Chuck, did you manage to do something with the comport.dll I sent to you?
Renaud
**** DISCLAIMER **** http://www.belgacom.be/maildisclaimer
Chuckk Hubbard wrote:
Interesting. I did get the comport.dll to work, thanks. My plan was to send PWM from my serial port, then use a low pass filter to obtain DC to control a Moog synthesizer's pitch. Christian Klippel, however, has kindly offered to create a USB->CV adaptor for me, something others have suggested but which has proven too confusing for me. I suspected that MSVC was not free.
This version is free as in beer: http://msdn.microsoft.com/vstudio/express/visualc/download/default.aspx
I found it easier than MinGW but I probably have a piece of wood somewhere in my brain...
Martin
[comport] compiles with MinGW for sure, donno about MSVC, if that's
what you mean.
.hc
On Nov 16, 2006, at 5:53 PM, Chuckk Hubbard wrote:
Interesting. I did get the comport.dll to work, thanks. My plan was to send PWM from my serial port, then use a low pass filter to obtain DC to control a Moog synthesizer's pitch. Christian Klippel, however, has kindly offered to create a USB->CV adaptor for me, something others have suggested but which has proven too confusing for me. I suspected that MSVC was not free. I wonder how hard it would be to adapt the makefile to MinGW? Thanks very much for sharing the .dll!
-Chuckk
On 11/16/06, renaud.herne@belgacom.be renaud.herne@belgacom.be
wrote:Hello List, Chuck,
While browsing the pd-extended distro I found 2 other patches
(than the comport.dll external) which allow us to take control of a serial portserial Which seems to be windows only (it doen't seem
there is a doc for this one) serialctl Which seems to be UNIX onlyBTW Chuck, did you manage to do something with the comport.dll I
sent to you?Renaud
**** DISCLAIMER **** http://www.belgacom.be/maildisclaimer
-- "Far and away the best prize that life has to offer is the chance to work hard at work worth doing." -Theodore Roosevelt
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war
on terrorism. - retired U.S. Army general, William Odom
I could only find the Ritsch version, and wasn't able to compile it with MinGW. The instructions assumed MSVC. Is there another version I didn't see?
On 11/17/06, Hans-Christoph Steiner hans@eds.org wrote:
[comport] compiles with MinGW for sure, donno about MSVC, if that's what you mean.
.hc
On Nov 16, 2006, at 5:53 PM, Chuckk Hubbard wrote:
Interesting. I did get the comport.dll to work, thanks. My plan was to send PWM from my serial port, then use a low pass filter to obtain DC to control a Moog synthesizer's pitch. Christian Klippel, however, has kindly offered to create a USB->CV adaptor for me, something others have suggested but which has proven too confusing for me. I suspected that MSVC was not free. I wonder how hard it would be to adapt the makefile to MinGW? Thanks very much for sharing the .dll!
-Chuckk
On 11/16/06, renaud.herne@belgacom.be renaud.herne@belgacom.be wrote:
Hello List, Chuck,
While browsing the pd-extended distro I found 2 other patches (than the comport.dll external) which allow us to take control of a serial port
serial Which seems to be windows only (it doen't seem there is a doc for this one) serialctl Which seems to be UNIX only
BTW Chuck, did you manage to do something with the comport.dll I sent to you?
Renaud
**** DISCLAIMER **** http://www.belgacom.be/maildisclaimer
-- "Far and away the best prize that life has to offer is the chance to work hard at work worth doing." -Theodore Roosevelt
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
Hi guys
i'm using pd-extend at the moment but i would like to switch to pd-0.40 and install all the libraries (or the libraries i need) by my self. I've downloaded PD 0.40-1 for OsX and the files pd-externals, pd-gem and pd-osc from SourceForge but there is something i can't understand, proceeding step by step:
1 are those recently version of externals, this gem version and pd-osc version? 1.a if no, i just have to download all this material from CVS?
2 have i to compile all the libraries one-by-one or i only have to set a startup path in the .pdrc file and put the libs in this path?
I'm on OsX 10.3.9 (Panther)
thank you very much for help!
Hi Francesco,
the best place to get the externals is by checking them out from CVS. To check out, follow the instructions here:
And there is a build script in the CVS folder. Go to the folder build/darwin and type "make". This will make all the externals in the script. This will not include GEM, pdp or any of the flext externals. You'll have to do those yourself. Then copy all (or only the ones you want) to pd/extra.
There are two problems here, which the Extended version tries to deal with. One is that the help files are still located in their individual folders, so you have to find a way of getting those over yourself. The other is that nameclashes are not resolved, so you will have several versions of things like [wrap] and other externals that share a common name. In same cases, using namespace [iem_wrap] can fix that problem. In Extended, all external libs are given a seperate folder in extra, and then you can load them by including that folder in your "path" setting in the PD interface.
Good luck, d.
Francesco wrote:
Hi guys
i'm using pd-extend at the moment but i would like to switch to pd-0.40 and install all the libraries (or the libraries i need) by my self. I've downloaded PD 0.40-1 for OsX and the files pd-externals, pd-gem and pd-osc from SourceForge but there is something i can't understand, proceeding step by step:
1 are those recently version of externals, this gem version and pd-osc version? 1.a if no, i just have to download all this material from CVS?
2 have i to compile all the libraries one-by-one or i only have to set a startup path in the .pdrc file and put the libs in this path?
I'm on OsX 10.3.9 (Panther)
thank you very much for help!
'ello Francesco, Pd-list,
On 17/11/2006, at 14.44, derek holzer wrote:
And there is a build script in the CVS folder. Go to the folder
build/darwin and type "make". This will make all the externals in
the script.
This might be trivial: In relation to your 'step 2' the externals
you'd like to install might very well depend on lib's you don't have
on the system by default, hence they are to be installed first.
What libs that each external depend on i don't know how to locate. A
comprehensive list would be very nice indeed.
Hi Steffan,
Steffen wrote:
'ello Francesco, Pd-list,
On 17/11/2006, at 14.44, derek holzer wrote:
And there is a build script in the CVS folder. Go to the folder build/darwin and type "make". This will make all the externals in the script.
This might be trivial: In relation to your 'step 2' the externals you'd like to install might very well depend on lib's you don't have on the system by default, hence they are to be installed first.
My impression is that the build script only does externals with no deps besides PD. Which is why GEM, PDP and the Flext externals (among others) are left out.
Deps for those libs depend very much on the functionality you want (Quicktime, Theonice, etc etc). You'll have to check each lib to see what functions and deps are there.
best, d.
On Nov 17, 2006, at 11:06 AM, derek holzer wrote:
Hi Steffan,
Steffen wrote:
'ello Francesco, Pd-list, On 17/11/2006, at 14.44, derek holzer wrote:
And there is a build script in the CVS folder. Go to the folder
build/darwin and type "make". This will make all the externals in
the script.This might be trivial: In relation to your 'step 2' the externals
you'd like to install might very well depend on lib's you don't
have on the system by default, hence they are to be installed first.My impression is that the build script only does externals with no
deps besides PD. Which is why GEM, PDP and the Flext externals
(among others) are left out.Deps for those libs depend very much on the functionality you want
(Quicktime, Theonice, etc etc). You'll have to check each lib to
see what functions and deps are there.
The Pd-extended build system can do basic dependencies with the .libs
file. Its a hack but its simple and works. For functional examples,
check out:
./bsaylor/partconv~.libs ./bsaylor/pvoc~.libs ./frankenstein/rhythms_memory.libs ./hardware/multio/multio.libs ./hcs/usbhid/usbhid.libs ./pdogg/oggamp~/oggamp~.libs ./pdogg/oggcast~/oggcast~.libs ./pdogg/oggread~/oggread~.libs ./pdogg/oggwrite~/oggwrite~.libs ./unauthorized/mp3amp~/mp3amp~.libs ./unauthorized/mp3cast~/mp3cast~.libs ./unauthorized/mp3live~/mp3fileout~.libs ./unauthorized/mp3live~/mp3streamin~.libs ./unauthorized/mp3live~/mp3streamout~.libs ./unauthorized/mp3write~/mp3write~.libs ./unauthorized/speex~/speexin~.libs ./unauthorized/speex~/speexout~.libs
.hc
http://at.or.at/hans/
I guess its not specifically documented, but [comport] is compiled as
part of the 'flatspace' library in the Pd-extended build system:
cd pure-data/externals make flatspace ls -l build/src/comport.dll
.hc
On Nov 17, 2006, at 12:15 AM, Chuckk Hubbard wrote:
I could only find the Ritsch version, and wasn't able to compile it with MinGW. The instructions assumed MSVC. Is there another version I didn't see?
On 11/17/06, Hans-Christoph Steiner hans@eds.org wrote:
[comport] compiles with MinGW for sure, donno about MSVC, if that's what you mean.
.hc
On Nov 16, 2006, at 5:53 PM, Chuckk Hubbard wrote:
Interesting. I did get the comport.dll to work, thanks. My plan was to send PWM from my serial port, then use a low pass filter to obtain DC to control a Moog synthesizer's pitch. Christian Klippel, however,
has
kindly offered to create a USB->CV adaptor for me, something others have suggested but which has proven too confusing for me. I suspected that MSVC was not free. I wonder how hard it would
be to
adapt the makefile to MinGW? Thanks very much for sharing the .dll!
-Chuckk
On 11/16/06, renaud.herne@belgacom.be renaud.herne@belgacom.be wrote:
Hello List, Chuck,
While browsing the pd-extended distro I found 2 other patches (than the comport.dll external) which allow us to take control of a
serial port
serial Which seems to be windows only (it doen't seem there is a doc for this one) serialctl Which seems to be UNIX only
BTW Chuck, did you manage to do something with the comport.dll I sent to you?
Renaud
**** DISCLAIMER **** http://www.belgacom.be/maildisclaimer
-- "Far and away the best prize that life has to offer is the
chance to
work hard at work worth doing." -Theodore Roosevelt
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
-- "Far and away the best prize that life has to offer is the chance to work hard at work worth doing." -Theodore Roosevelt
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
On 16/11/2006, at 23.53, Chuckk Hubbard wrote:
My plan was to send PWM from my serial port, then use a low pass
filter to obtain DC to control a Moog synthesizer's pitch.
I don't quite understand how a PWM'ed signal put through a low pass
filter can give a voltage controlling signal. Care to explain? I'm
not even sure how to make the PWM signal at all - will it only be
using one pin? I might be daft.
I thought the easiest way to obtain such a signal from a serial port,
was to make a D/A converter fx with a transistor construction
(couldn't just find a diagram on the internet), such that each bit
sent to the port would translate to a DC signal. I know the precision
of the values might be sloppy and that there will only be 2^{# of
data pins on the port} different control values to mess with - but
still?
I read about it in Delton T. Horns Music Synthesizers: A Manual of
Design and Construction, if i recall correct, where the author
suggested to use a S/H in connection with such a converter to save
CPU power (when one wanted to keep a given CV for a period of time
(faster then the port)).
Christian Klippel, however, has kindly offered to create a USB->CV
adaptor for me, something others have suggested but which has
proven too confusing for me.
That's very nice. I'd really love to make such a lil' donkey myself.
hi steffen,
Am Freitag, 17. November 2006 17:26 schrieb Steffen:
On 16/11/2006, at 23.53, Chuckk Hubbard wrote:
My plan was to send PWM from my serial port, then use a low pass filter to obtain DC to control a Moog synthesizer's pitch.
I don't quite understand how a PWM'ed signal put through a low pass filter can give a voltage controlling signal. Care to explain? I'm not even sure how to make the PWM signal at all - will it only be using one pin? I might be daft.
imagine you have a always repeating loop from 0 to 255. now compare the wanted pwm value with the counter. if the counter is smaller, you turn on the pin, when it is bigger, you turn it of.
that way you have 256 step cycle of always the same length, while the output is on (+5 volts), lets say, for 128 steps (50%), ond off (0 volts) for the remaining 128. in fact, it is a pulse with a fixed frequency but variable pulse width.
if you feed that through a r/c lowpass, the resulting output is an average of 2.5 volts (50% of 5 volts).
I thought the easiest way to obtain such a signal from a serial port, was to make a D/A converter fx with a transistor construction (couldn't just find a diagram on the internet), such that each bit sent to the port would translate to a DC signal. I know the precision of the values might be sloppy and that there will only be 2^{# of data pins on the port} different control values to mess with - but still?
its not done with transistors, but resistors. there are serveral methods, but the most common used i think are binary-weighted resistor dacs, and r-2r dacs. the first one uses one resistor per dataline, increasing by powers of two (like, 500 ohms, 1kohm, 2kohm, 4kohm,....). the second one uses only two different resistor values, but twice as many resistors in total.
the problem is the accuracy. a binary weighted dac you can build yourself only with very few bits. since the values rise in powers of two, the tolerance of the highest-valued resistor may be already more than the total value of the smalles resistor.
a r-2r dac is a bit better, but still for many bits, it is too inaccurate when you build it with standard components.
a small overview of how dac's are constructed (figure 1 and 4 are the the ones i talked about): http://www.analog.com/en/content/0,2886,761%255F795%255F91287,00.html
note that while dac chips actually use these techniques, you will fail to build such a dac yourself with good enough accuracy. in the chips, they use highly precise, and often laser-trimmed, resistors (usually on-die).
I read about it in Delton T. Horns Music Synthesizers: A Manual of Design and Construction, if i recall correct, where the author suggested to use a S/H in connection with such a converter to save CPU power (when one wanted to keep a given CV for a period of time (faster then the port)).
this is only usefull if you want to digitize a changing signal. you use the s&h circuit (usually just a capacitor and a switch) to "freeze" the current value, so it stays stable while you digitze it. to digitize a signal, you basically need a dac, s&h and comparator. you load the s&h, set a value at the dac, and compare the two voltages with the comparator. you change the dac value so long until you have a match between the two voltages. then you discharge the s&h, and go ahead with the next sample.
Christian Klippel, however, has kindly offered to create a USB->CV adaptor for me, something others have suggested but which has proven too confusing for me.
That's very nice. I'd really love to make such a lil' donkey myself.
once it is built and working, i will put it online.
greets,
chris
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Christian Klippel wrote:
Am Freitag, 17. November 2006 17:26 schrieb Steffen:
I read about it in Delton T. Horns Music Synthesizers: A Manual of Design and Construction, if i recall correct, where the author suggested to use a S/H in connection with such a converter to save CPU power (when one wanted to keep a given CV for a period of time (faster then the port)).
this is only usefull if you want to digitize a changing signal. you use the s&h circuit (usually just a capacitor and a switch) to "freeze" the current value, so it stays stable while you digitze it. to digitize a signal, you basically need a dac, s&h and comparator. you load the s&h, set a value at the dac, and compare the two voltages with the comparator. you change the dac value so long until you have a match between the two voltages. then you discharge the s&h, and go ahead with the next sample.
Not only useful for digitizing an analog sample into the digital world, but also useful as a multiplexer. If you build a converter using one single ADC, you could share it to say 8 channels by sending them one at a time. Often (but not always) cheaper and easier than using 8 normal ADC's. Multiplexing with S&H works even on a low pass filtered PWM-signal if thats what someone (?) was planning on using...
mvh//Svante - with a homebuilt midi to 8-channel CV somewhere in some drawer...
hello svante,
Am Freitag, 17. November 2006 18:57 schrieb Svante Hermansson:
Christian Klippel wrote:
Am Freitag, 17. November 2006 17:26 schrieb Steffen:
I read about it in Delton T. Horns Music Synthesizers: A Manual of Design and Construction, if i recall correct, where the author suggested to use a S/H in connection with such a converter to save CPU power (when one wanted to keep a given CV for a period of time (faster then the port)).
this is only usefull if you want to digitize a changing signal. you use the s&h circuit (usually just a capacitor and a switch) to "freeze" the current value, so it stays stable while you digitze it. to digitize a signal, you basically need a dac, s&h and comparator. you load the s&h, set a value at the dac, and compare the two voltages with the comparator. you change the dac value so long until you have a match between the two voltages. then you discharge the s&h, and go ahead with the next sample.
Not only useful for digitizing an analog sample into the digital world, but also useful as a multiplexer. If you build a converter using one single ADC, you could share it to say 8 channels by sending them one at a time. Often (but not always) cheaper and easier than using 8 normal ADC's. Multiplexing with S&H works even on a low pass filtered PWM-signal if thats what someone (?) was planning on using...
you are right. but that also implies that the outputs are updated periodically, even if the value doesnt change. also, you need a buffering op-amp with high input impedance, to keep the voltage stable between the updates (a too high load will discharge the cap in the s&h). that continous update may also cause some ripple on the output, a thing that needs to be considered if you go for high resolution, like 16 bits....
nowdays you can get 8 channel, 12 bit dac's (like the tlv5610) for a low price, so i doubt that it is worth going the s&h way nowdays.
greets,
chris
mvh//Svante - with a homebuilt midi to 8-channel CV somewhere in some drawer...
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
oh, and:
Am Freitag, 17. November 2006 18:57 schrieb Svante Hermansson:
single ADC, you could share it to say 8 channels by sending them one at
[...]
ADC's. Multiplexing with S&H works even on a low pass filtered
i assume you meant dac's instead ;)
greets,
chris
Christian Klippel wrote:
oh, and:
Am Freitag, 17. November 2006 18:57 schrieb Svante Hermansson:
single ADC, you could share it to say 8 channels by sending them one at
[...]
ADC's. Multiplexing with S&H works even on a low pass filtered
i assume you meant dac's instead ;)
Ahhh, of course. DAC's it is! Thanks! :)
mvh//Svante
Yeah.
On 11/17/06, Christian Klippel ck@mamalala.de wrote:
hi steffen,
Am Freitag, 17. November 2006 17:26 schrieb Steffen:
On 16/11/2006, at 23.53, Chuckk Hubbard wrote:
My plan was to send PWM from my serial port, then use a low pass filter to obtain DC to control a Moog synthesizer's pitch.
I don't quite understand how a PWM'ed signal put through a low pass filter can give a voltage controlling signal. Care to explain? I'm not even sure how to make the PWM signal at all - will it only be using one pin? I might be daft.
imagine you have a always repeating loop from 0 to 255. now compare the wanted pwm value with the counter. if the counter is smaller, you turn on the pin, when it is bigger, you turn it of.
that way you have 256 step cycle of always the same length, while the output is on (+5 volts), lets say, for 128 steps (50%), ond off (0 volts) for the remaining 128. in fact, it is a pulse with a fixed frequency but variable pulse width.
if you feed that through a r/c lowpass, the resulting output is an average of 2.5 volts (50% of 5 volts).
I thought the easiest way to obtain such a signal from a serial port, was to make a D/A converter fx with a transistor construction (couldn't just find a diagram on the internet), such that each bit sent to the port would translate to a DC signal. I know the precision of the values might be sloppy and that there will only be 2^{# of data pins on the port} different control values to mess with - but still?
its not done with transistors, but resistors. there are serveral methods, but the most common used i think are binary-weighted resistor dacs, and r-2r dacs. the first one uses one resistor per dataline, increasing by powers of two (like, 500 ohms, 1kohm, 2kohm, 4kohm,....). the second one uses only two different resistor values, but twice as many resistors in total.
the problem is the accuracy. a binary weighted dac you can build yourself only with very few bits. since the values rise in powers of two, the tolerance of the highest-valued resistor may be already more than the total value of the smalles resistor.
a r-2r dac is a bit better, but still for many bits, it is too inaccurate when you build it with standard components.
a small overview of how dac's are constructed (figure 1 and 4 are the the ones i talked about): http://www.analog.com/en/content/0,2886,761%255F795%255F91287,00.html
note that while dac chips actually use these techniques, you will fail to build such a dac yourself with good enough accuracy. in the chips, they use highly precise, and often laser-trimmed, resistors (usually on-die).
I read about it in Delton T. Horns Music Synthesizers: A Manual of Design and Construction, if i recall correct, where the author suggested to use a S/H in connection with such a converter to save CPU power (when one wanted to keep a given CV for a period of time (faster then the port)).
this is only usefull if you want to digitize a changing signal. you use the s&h circuit (usually just a capacitor and a switch) to "freeze" the current value, so it stays stable while you digitze it. to digitize a signal, you basically need a dac, s&h and comparator. you load the s&h, set a value at the dac, and compare the two voltages with the comparator. you change the dac value so long until you have a match between the two voltages. then you discharge the s&h, and go ahead with the next sample.
Christian Klippel, however, has kindly offered to create a USB->CV adaptor for me, something others have suggested but which has proven too confusing for me.
That's very nice. I'd really love to make such a lil' donkey myself.
once it is built and working, i will put it online.
greets,
chris
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
-
Christian Klippel -
Chuckk Hubbard -
derek holzer -
Francesco -
Hans-Christoph Steiner -
Martin Peach -
renaud.herne＠belgacom.be -
Steffen -
Svante Hermansson