I am using pd-0.31 on an Athlon-based system running Redhat 6.2 and ALSA. There is a Hammerfall and a Trident 4DNX in there.
Every time I start pd, it complains about how it cannot connect to the network (101). No windows appear (I'm not sure that they should. In the manual it said I'd see a window at this point, but who knows?).
Any help appreciated. Thanks for putting up with a newbie.
(jfm3)
|I am using pd-0.31 on an Athlon-based system running Redhat 6.2 and |ALSA. There is a Hammerfall and a Trident 4DNX in there. | |Every time I start pd, it complains about how it cannot connect to the |network (101). No windows appear (I'm not sure that they should. In the |manual it said I'd see a window at this point, but who knows?).
check wether your lo (127.0.0.1) interface = up ..
btw list: its time for an faq, faq-o-matic or something ?
-- X d v . 0 R G
On Sun, Feb 11, 2001 at 09:48:54AM +1030, pix@test.at wrote:
On Sat, 10 Feb 2001, [ISO-8859-1] _-¯-_ wrote:
btw list: its time for an faq, faq-o-matic or something ?
this is a great idea... do we politely ask iem?
or does someone else want to host it?
pix.
hello,
you are very polite indeed. i 'd like to expand the iem web pages and pure database - but don't expect things too soon ... of course if somebody wants to contribute (suggestions are welcome too) it would drastically increase the speed and quality of the service. btw - does somebody have any experience in setting up a faq-o-matic? does it make sense to use zope?
norbert
I have posted an implementation of the k-NN algorithm as a pd object to my website:
mambo.peabody.jhu.edu/~karlmac/download/pd/knn.tar.gz
There is a help patch and a readme, but they are probably not that much help. Feel free to ask me questions. The general idea is that objects can be classified by their feature vector (just a pd list of floating point numbers - the numbers can refer to anything i.e. size, shape, spectral features, etc.). You train the classifier by inputting known feature vectors. After the training is complete you can input an unknown feature vector which will be assigned the same classification as the majority of the k (k is a small number like 3 or 5) closest feature vectors in the database (nearest neighbors). The classification is pretty quick as the entire database is in ram and is usually pretty small (a few hundred to a few thousand).
This implementation also has the ability to weight features - that is give more importance to a certain feature. This is done with a vector the same size as the feature vector with weights between 0 and 1. The default is to treat all of the features equally. I have some code that will determine the optimum weights for a database using a genetic algorithm - I will release this after I clean it up a bit.
Here at Peabody we have used a k-NN classifier to successfully recognize sheet music (http://mambo.peabody.jhu.edu/omr) and timbre (I will post papers about this soon). At this point I should give credit to Dr. Ichiro Fujinaga who has done most of this research - I am his graduate student and helped with the implementation and some of the research, but he is the one that deserves most of the credit.
One problem with the current implementation is the the length of the feature vectors and the maximum number of classes is fixed at compile time. If this is really a problem for anyone let me know.
Karl
| Karl W. MacMillan | | Computer Music Department | | Peabody Institute of the Johns Hopkins University | | karlmac@peabody.jhu.edu | | www.peabody.jhu.edu/~karlmac |
as it seems to fit in : if someone is interested right now, i can put my implementation of a self-organized map (SOM), featuring instar, outstar and kohonen learning rules on the web too. on the other hand, i just wanted to wait, till i had a number of "artificial neural network" objects to be released as a more or less complete library. but since i had no time to work on it for at least the last 4 weeks and i do not know what is to come, maybe this would be in summer or even later.
if anyone is interested, just mail to me.
mfg.fgds.gre IOhannes
Hi all,
I have added supported support for the newest alsa drivers to PD. There is source and an intel binary at:
http://mambo.peabody.jhu.edu/~karlmac/download/pd/
This should work with the alsa cvs version as of a few days ago or the newest beta available on the alsa website (www.alsa-project.org). It is currently limited to 16/24 bit interleaved cards - i.e. no hammerfall. I have only tested it on a stereo 16 bit card. Either Winfried Ritsch or I will produce an optimized version for the hammerfall soon (still interested in doing this Winfried?). Finally, you will probably need to set the number of frags to make it work at all. Try this commandline first:
./pd -alsa -frags 20
I know this seems like a lot of fragments, but this is comprable latency to OSS on my machine. Please test this and tell me how it works or doesn't work. Miller, if you would like a diff just let me know.
Karl
| Karl W. MacMillan | | Computer Music Department | | Peabody Institute of the Johns Hopkins University | | karlmac@peabody.jhu.edu | | www.peabody.jhu.edu/~karlmac |
Hello,
This should work with the alsa cvs version as of a few days ago or the newest beta available on the alsa website (www.alsa-project.org). It is currently limited to 16/24 bit interleaved cards - i.e. no hammerfall. I have only tested it on a stereo 16 bit card. Either Winfried Ritsch or I will produce an optimized version for the hammerfall soon (still interested in doing this Winfried?). Finally, you will probably need to set the number of frags to make it work at all. Try this commandline first:
yes I am on the way, but the alsa-mmap interface was just changed again the last days ;-(, even there is one problem, that is you cannot allocate a subset of channels in mmap on alsa so always have to use all 26 (18) channels, which is not always preferabel. Maybe we just should integrate the non-interleaved no-mmap interface also in your driver-interface or using "plugin:" for these cases and a special mmap one for really low latency for all channels ?
One other idea is that the driver allocates all channels but fill only these which are needed, so an performance improvement could be that the adc~/dac~ object reports or are asked in some way if they are allocated, so only these channels are copy/converted from/to float to/from card-format.
I know this seems like a lot of fragments, but this is comprable latency to OSS on my machine. Please test this and tell me how it works or doesn't work. Miller, if you would like a diff just let me know.
ok, the option -noadc and -nodac does a: pd: pcm_params.c:2081: snd_pcm_hw_refine: Assertion `pcm && params' failed.
mfg winfried
On Fri, 20 Apr 2001, Winfried Ritsch wrote:
Hello,
This should work with the alsa cvs version as of a few days ago or the newest beta available on the alsa website (www.alsa-project.org). It is currently limited to 16/24 bit interleaved cards - i.e. no hammerfall. I have only tested it on a stereo 16 bit card. Either Winfried Ritsch or I will produce an optimized version for the hammerfall soon (still interested in doing this Winfried?). Finally, you will probably need to set the number of frags to make it work at all. Try this commandline first:
yes I am on the way, but the alsa-mmap interface was just changed again the last days ;-(, even there is one problem, that is you cannot allocate a subset of channels in mmap on alsa so always have to use all 26 (18) channels, which is not always preferabel. Maybe we just should integrate the non-interleaved no-mmap interface also in your driver-interface or using "plugin:" for these cases and a special mmap one for really low latency for all channels ?
Hmmm, I am adding a command line switch right now to allow the user to choose the plugin layer. This seems like a good compromise to me - it will allow the user to choose whether they want performance or flexibility.
Also, I think I will start separating the perform functions instead of dumping all possible combinations into 1 long function. Are there any objections to using the gcc specific inline keyword in the alsa code? If you are using alsa you _must_ be using gcc as far as I know so this seems safe.
One other idea is that the driver allocates all channels but fill only these which are needed, so an performance improvement could be that the adc~/dac~ object reports or are asked in some way if they are allocated, so only these channels are copy/converted from/to float to/from card-format.
This seems like a good idea as well. Maybe instead of the adc~/dac~ it can be the number of devices requested on the command line. This would require fewer changes in the code and be simplier overall.
I know this seems like a lot of fragments, but this is comprable latency to OSS on my machine. Please test this and tell me how it works or doesn't work. Miller, if you would like a diff just let me know.
ok, the option -noadc and -nodac does a: pd: pcm_params.c:2081: snd_pcm_hw_refine: Assertion `pcm && params' failed.
This is fixed in my local copy. I will upload another version after I here from some more people.
Karl
mfg winfried
| Karl W. MacMillan | | Computer Music Department | | Peabody Institute of the Johns Hopkins University | | karlmac@peabody.jhu.edu | | www.peabody.jhu.edu/~karlmac |
I decided to go ahead and put up a modified pd with alsa support:
mambo.peabody.jhu.edu/~karlmac/download/pd/pd-032PATCH6-alsa2-linux.tar.gz
This changes -alsadev to allow you to specify the device name - the defualt is still "hw:0,0". It also fixes the bug preventing the use of -noadc and -nodac.
Karl
| Karl W. MacMillan | | Computer Music Department | | Peabody Institute of the Johns Hopkins University | | karlmac@peabody.jhu.edu | | www.peabody.jhu.edu/~karlmac |
I've merged Karl's version with mine (it now conditionally compiles for ALSA 0.5 or 0.9). I'm haveing some trouble getting the 0.9 part to work. On my soundblaster the audio output is an octave down (as if the card were getting addressed in mono.)... my Midiman Delta 66 isn't working at all. I'll try to get this debugged but in the meantime the merged source code is sitting in:
http://crca.ucsd.edu/~msp/Software/pd-src.tar.gz
cheers Miller
On Fri, Apr 20, 2001 at 12:17:57PM -0400, Karl MacMillan wrote:
I decided to go ahead and put up a modified pd with alsa support:
mambo.peabody.jhu.edu/~karlmac/download/pd/pd-032PATCH6-alsa2-linux.tar.gz
This changes -alsadev to allow you to specify the device name - the defualt is still "hw:0,0". It also fixes the bug preventing the use of -noadc and -nodac.
Karl
| Karl W. MacMillan | | Computer Music Department | | Peabody Institute of the Johns Hopkins University | | karlmac@peabody.jhu.edu | | www.peabody.jhu.edu/~karlmac |
Great! Not certain about the problems that you are having - I will be interested to see the solution. I tried to do a pretty straight port of the 0.5 code so it is a little surprising that things don't work. Almost the only change in alsa_send_dacs is to switch from bytes to frames. The alsa api might be changing again, by the way (this constant change is, to say the least, tiresome). Maybe a formal release should wait until alsa 1.0 comes out, whenever that is!
Karl
On Sun, 22 Apr 2001, Miller Puckette wrote:
I've merged Karl's version with mine (it now conditionally compiles for ALSA 0.5 or 0.9). I'm haveing some trouble getting the 0.9 part to work. On my soundblaster the audio output is an octave down (as if the card were getting addressed in mono.)... my Midiman Delta 66 isn't working at all. I'll try to get this debugged but in the meantime the merged source code is sitting in:
http://crca.ucsd.edu/~msp/Software/pd-src.tar.gz
cheers Miller
On Fri, Apr 20, 2001 at 12:17:57PM -0400, Karl MacMillan wrote:
I decided to go ahead and put up a modified pd with alsa support:
mambo.peabody.jhu.edu/~karlmac/download/pd/pd-032PATCH6-alsa2-linux.tar.gz
This changes -alsadev to allow you to specify the device name - the defualt is still "hw:0,0". It also fixes the bug preventing the use of -noadc and -nodac.
Karl
| Karl W. MacMillan | | Computer Music Department | | Peabody Institute of the Johns Hopkins University | | karlmac@peabody.jhu.edu | | www.peabody.jhu.edu/~karlmac |
| Karl W. MacMillan | | Computer Music Department | | Peabody Institute of the Johns Hopkins University | | karlmac@peabody.jhu.edu | | www.peabody.jhu.edu/~karlmac |
Well, looking at the code there are two problems:
- change lines 1715 and 1797 from the form
err = snd_pcm_hw_params_set_channels_max(alsa_device.outhandle, hw_params, &outchans); to
err = snd_pcm_hw_params_set_channels(alsa_device.outhandle, hw_params, outchans);
The max function doesn't seem to be reliable or at least do what I expect. All of these functions need to be looked at. The deal is that alsa-lib is supposed to have functions that say 'set to this value or the closest valid value above/below/whatever' but I have never been able to make them work reliably. The plain set_* functions will fail if the exact param cannot be set, which is hardly ideal. The last time I really tested all of this was before the beta versions came out, so maybe things are improved. I will check.
- change lines 1918 and 1919 to equal DACBLKSIZE instead of DACBLKSIZE *
nchannels. In the debugging process this got set to incorrectly. This makes the alsa_send_dacs function actually deal with frames :)
Hope this helps,
Karl
P.S. To make things less confusing I am removing my pd versions from my website.
On Sun, 22 Apr 2001, Karl MacMillan wrote:
Great! Not certain about the problems that you are having - I will be interested to see the solution. I tried to do a pretty straight port of the 0.5 code so it is a little surprising that things don't work. Almost the only change in alsa_send_dacs is to switch from bytes to frames. The alsa api might be changing again, by the way (this constant change is, to say the least, tiresome). Maybe a formal release should wait until alsa 1.0 comes out, whenever that is!
Karl
On Sun, 22 Apr 2001, Miller Puckette wrote:
I've merged Karl's version with mine (it now conditionally compiles for ALSA 0.5 or 0.9). I'm haveing some trouble getting the 0.9 part to work. On my soundblaster the audio output is an octave down (as if the card were getting addressed in mono.)... my Midiman Delta 66 isn't working at all. I'll try to get this debugged but in the meantime the merged source code is sitting in:
http://crca.ucsd.edu/~msp/Software/pd-src.tar.gz
cheers Miller
On Fri, Apr 20, 2001 at 12:17:57PM -0400, Karl MacMillan wrote:
I decided to go ahead and put up a modified pd with alsa support:
mambo.peabody.jhu.edu/~karlmac/download/pd/pd-032PATCH6-alsa2-linux.tar.gz
This changes -alsadev to allow you to specify the device name - the defualt is still "hw:0,0". It also fixes the bug preventing the use of -noadc and -nodac.
Karl
| Karl W. MacMillan | | Computer Music Department | | Peabody Institute of the Johns Hopkins University | | karlmac@peabody.jhu.edu | | www.peabody.jhu.edu/~karlmac |
| Karl W. MacMillan | | Computer Music Department | | Peabody Institute of the Johns Hopkins University | | karlmac@peabody.jhu.edu | | www.peabody.jhu.edu/~karlmac |
| Karl W. MacMillan | | Computer Music Department | | Peabody Institute of the Johns Hopkins University | | karlmac@peabody.jhu.edu | | www.peabody.jhu.edu/~karlmac |
OK... that helped my SB a lot. I've put my latest fold-in on:
http://www.crca.ucsd.edu/~msp/Software/pd-033TEST1.tar.gz
There's much still needing to be fixed, but I'll call it a night...
cheers Miller
On Sun, Apr 22, 2001 at 06:48:04PM -0400, Karl MacMillan wrote:
Well, looking at the code there are two problems:
...(etc)
-
_-¯-_ -
jfm3 -
Johannes M Zmoelnig -
Karl MacMillan -
Miller Puckette -
Norbert Math -
pix＠test.at -
Winfried Ritsch