Also, is it possible to have an array report its size somewhere other than the Pd window?
use "arraysize"
error: array: no method for 'arraysize'
"print" makes it send its size to the Pd window, but I'm wondering if Pd itself can tell.
Chuckk Hubbard wrote:
Also, is it possible to have an array report its size somewhere other than the Pd window?
use "arraysize"
error: array: no method for 'arraysize'
i think "arraysize" is really an (external) object [arraysize] and not a message [arraysize(.
mfg.adsr IOhannes
Also, is it possible to have an array report its size somewhere other than the Pd window?
use "arraysize"
error: array: no method for 'arraysize'
"print" makes it send its size to the Pd window, but I'm wondering if Pd itself can tell.
sorry, I meant the external arraysize. if you can't find it I can send it
directly
Hi,
i have a problem with audio output on Linux with the RME Madi-card. I use Alsa and it seems ok, but i get only one input and output channel. My pdsettings are set up for 64 input and output channels.
PD says
- requested channels=0 but used=1
- playback device with 1 channels and buffer_time 42666 us opened
- requested channels=0 but used=1
when i turn the audio on.
Any hint? Or has anybody ever got pd to run as many channels?
Thanks,
Jérome
Quoting "J. Schmidt" schmidje@idmt.fraunhofer.de:
Hi,
i have a problem with audio output on Linux with the RME Madi-card. I use Alsa and it seems ok, but i get only one input and output channel. My pdsettings are set up for 64 input and output channels.
PD says
- requested channels=0 but used=1
- playback device with 1 channels and buffer_time 42666 us opened
- requested channels=0 but used=1
when i turn the audio on.
Any hint? Or has anybody ever got pd to run as many channels?
yes, we (the iem) are using the MADI card with 64 channels.
the problem is, that pd (0.39.2) seems to just ignores the channel# when doing alsa (or is it some special thing like alsamm, dunno) and defaults it to 0. when it comes to opening the device, pd queries the device about the max. and min. number of channels the device supports. now the madi has a minimum of 1 channels and a maximum of 64 channels. the requested number of channels (in our case 0! because the number of channels you typed in ist just ignored!!) is clamped between these 2 values, which results in 1. that is why you only get 1 channel.
i think this doesn't happen on other devices, because most of them just support one fixed number of channels (min.chan==max.chan)
now what to do against it? i have once patched the s_audio_alsa.c, so that if the requested channel is 0, this value is not clamped between the min. and max. #channels but rather set to the max. #channels. i will see if i can find it. wini (who - as you probably know - has written both the madi-drivers and the original memory-mapped alsa support for pd) has done something different to make it work, but i don't know what exactly.
of course, the cleanest solution would be to not-ignore the number of channels requested by the user.
mfg.a.r IOhannes
zmoelnig@iem.at wrote:
Quoting "J. Schmidt" schmidje@idmt.fraunhofer.de:
Hi,
i have a problem with audio output on Linux with the RME Madi-card. I use Alsa and it seems ok, but i get only one input and output channel. My pdsettings are set up for 64 input and output channels.
PD says
- requested channels=0 but used=1
- playback device with 1 channels and buffer_time 42666 us opened
- requested channels=0 but used=1
when i turn the audio on.
Any hint? Or has anybody ever got pd to run as many channels?
yes, we (the iem) are using the MADI card with 64 channels.
the problem is, that pd (0.39.2) seems to just ignores the channel# when doing alsa (or is it some special thing like alsamm, dunno) and defaults it to 0. when it comes to opening the device, pd queries the device about the max. and min. number of channels the device supports. now the madi has a minimum of 1 channels and a maximum of 64 channels. the requested number of channels (in our case 0! because the number of channels you typed in ist just ignored!!) is clamped between these 2 values, which results in 1. that is why you only get 1 channel.
i think this doesn't happen on other devices, because most of them just support one fixed number of channels (min.chan==max.chan)
now what to do against it? i have once patched the s_audio_alsa.c, so that if the requested channel is 0, this value is not clamped between the min. and max. #channels but rather set to the max. #channels. i will see if i can find it.
Would be glad to get it!
wini (who - as you probably know - has written both the madi-drivers and the original memory-mapped alsa support for pd) has done something different to make it work, but i don't know what exactly.
of course, the cleanest solution would be to not-ignore the number of channels requested by the user.
mfg.a.r IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Mfg jerome
J. Schmidt wrote:
zmoelnig@iem.at wrote:
now what to do against it? i have once patched the s_audio_alsa.c, so that if the requested channel is 0, this value is not clamped between the min. and max. #channels but rather set to the max. #channels. i will see if i can find it.
Would be glad to get it!
i just made this little patch which _should_ do the trick.
i haven't really tested it at all (i have no MADI here at home and i am too lazy to compile... :-)), but i am pretty sure it will work.
mfg.adsr. IOhannes
Hello,
the problem is in fact a wrong behaviour of PD on multichannel cards. Most Hammerfall has a fixed number of channels, but on dsp-madi you can choose and in fact it does not use enable all of the channels on hardware which means reduction in the PCI-load. so channels can be chossen from 1 to 64. (In fact all hdsp can do this but it is not implemented on the alsa-driver).
So the best way would be to respect the channel count from the user and if you use more than 64 it looks for the next multichannel card, so if you use 4 madis (maximum) you have 256 channels.
I will make a patch with a cleaner solution soon, and also made an PD-external to use the 128x64 Mixer. from PD (since alsactl cant store all values of the matrix, so on startup you may have differennt settings).
Please tell me if you experience other problems, sind HDSP-Madi is not tested very much on different linux machines.
mfg winfried ritsch.
zmoelnig@iem.at wrote:
now what to do against it? i have once patched the s_audio_alsa.c, so that if the requested channel is 0, this value is not clamped between the min. and max. #channels but rather set to the max. #channels. i will see if i can find it.
Would be glad to get it!
i just made this little patch which _should_ do the trick.
i haven't really tested it at all (i have no MADI here at home and i am too lazy to compile... :-)), but i am pretty sure it will work.
On Mar 24, 2006, at 5:37 AM, João Miguel Pais wrote:
Also, is it possible to have an array report its size somewhere
other
than the Pd window?
use "arraysize"
error: array: no method for 'arraysize'
"print" makes it send its size to the Pd window, but I'm wondering if Pd itself can tell.
sorry, I meant the external arraysize. if you can't find it I can
send it directly
[arraysize] is in Pd-extended.
(I sound like a broken record, don't I? ;)
.hc
-- Lugostr. 14 79100 Freiburg i. Br. Deutschland +49 (0)761 7074997 jmmmpais@googlemail.com http://www.puredata.org/Members/jmmmp
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
¡El pueblo unido jamás será vencido!
On Fri, 24 Mar 2006, Hans-Christoph Steiner wrote:
[arraysize] is in Pd-extended. (I sound like a broken record, don't I? ;)
It's cause your audience listens like a broken mic ;-)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
Chuckk Hubbard -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
J. Schmidt -
João Miguel Pais -
Mathieu Bouchard -
Winfried Ritsch -
zmoelnig＠iem.at