hello,
quite a retro-question, but maybe someone can help:
currently i'm working with PDa on a gumstix computer.
PDa is based on pd 0.37.4 and it doesn't contain the list objects.
since i do a lot of list processing, it would be nice to have those
on the gumstix, too.
so, i took the source (x_list.c) from a recent version, cross
compiled it for the gumstix and installed the object in /usr/lib/pd/
externs.
this is working fine.
only drawback is, that everytime i run pd, i have to create a
[x_list] object before i can use any of the list objects, like [list
append], [list trim] etc. so i have to somehow load the object into
memory. not a big issue, but can be annoying.
in newer versions of pd this is done automatically.
(i guess you call this an "interal" as opposed to "external"?)
how could i apply the same auto-load mechanism in this situation?
thanks for your comments, volker.
Hallo, volker b?hm hat gesagt: // volker b?hm wrote:
quite a retro-question, but maybe someone can help: currently i'm working with PDa on a gumstix computer. PDa is based on pd 0.37.4 and it doesn't contain the list objects. since i do a lot of list processing, it would be nice to have those
on the gumstix, too. so, i took the source (x_list.c) from a recent version, cross
compiled it for the gumstix and installed the object in /usr/lib/pd/ externs. this is working fine. only drawback is, that everytime i run pd, i have to create a
[x_list] object before i can use any of the list objects, like [list
append], [list trim] etc. so i have to somehow load the object into
memory. not a big issue, but can be annoying. in newer versions of pd this is done automatically. (i guess you call this an "interal" as opposed to "external"?)how could i apply the same auto-load mechanism in this situation?
Maybe add x_list_setup() to m_conf.c, if that is part of PDa.
Ciao
Frank
volker böhm wrote:
hello, quite a retro-question, but maybe someone can help: currently i'm working with PDa on a gumstix computer. PDa is based on pd 0.37.4 and it doesn't contain the list objects. since i do a lot of list processing, it would be nice to have those
on the gumstix, too. so, i took the source (x_list.c) from a recent version, cross
compiled it for the gumstix and installed the object in /usr/lib/pd/ externs. this is working fine. only drawback is, that everytime i run pd, i have to create a
[x_list] object before i can use any of the list objects, like [list
append], [list trim] etc. so i have to somehow load the object into
memory. not a big issue, but can be annoying.
maybe:
- rename the x_list_setup() function in the source code to list_setup()
- recompile
- copy the compiled file to list.foo (where foo is the appropriate
extension for gumstix pda)
untested as i don't have a pda :)
then what should happen is that the list.foo is loaded automatically when you try and create a [list ...] object, so no more problems as all the [list foo] objects have that weird [list] redirector.
the classical solution would be to do:
pd -lib x_list
which would load x_list.foo and run x_list_setup() when pd starts
in newer versions of pd this is done automatically.
in newer pd it's built into the pd binary, so no hope of fiddling with it to upgrade it without recompiling the whole of pd
(i guess you call this an "interal" as opposed to "external"?)
yes, internal vs external - imo as much as possible should be externally loaded with pd core being super minimal - but one can dream of potatoes..
how could i apply the same auto-load mechanism in this situation?
thanks for your comments, volker.
Claude
hey, thanks for the pointers.
Maybe add x_list_setup() to m_conf.c, if that is part of PDa.
yes, this works fine on the host computer.
but, that'd mean i'd have to cross compile the whole PDa source.
haven't managed to get that right, yet.
at the moment i'm working with a pre-built package for the gumstix.
maybe:
- rename the x_list_setup() function in the source code to
list_setup() 2. recompile 3. copy the compiled file to list.foo (where foo is the appropriate
extension for gumstix pda)
haven't quite understood the third step. you mean to change the name
of the x_list.pd_linux file (extensions are the same as for pd on
normal linux) to list.pd_linux?
the classical solution would be to do:
pd -lib x_list
cool, that's an easy one and also works on the gumstix.
it's what i'm using right now.
as i have to pass some other command line option anyway i can just
add the -lib to my startup script.
have to read up on differences of internals,externals and libs. just found the "how to" by iohannes zmoelnig..
thanks, guys. angenehme feiertage! volker.
ps: why is the return address not set to the list automatically?
most of the time one wants to send return mails to the list and not
to the individual member, no?
i keep falling into that trap over and over...
Hallo, volker b?hm hat gesagt: // volker b?hm wrote:
ps: why is the return address not set to the list automatically? most of the time one wants to send return mails to the list and not
to the individual member, no? i keep falling into that trap over and over...
That's saver than falling into the trap of sending mails meant to be private to over 1500 other readers, which happens more often on Reply-to-munging lists. Also see: http://puredata.info/community/lists/Netiquette
Ciao
Frank
hey,
i'm running Pd vanilla 0.41-0 on Ubuntu Intrepid, and trying to get it to play nice with pulseaudio (setup as an alsa plugin) is proving difficult.
if i choose 'alsa', i have two options for devices, 'HDA Intel (hardware)' and 'HDA Intel (plug-in)'. I assume that 'plug-in' ought to connect through the pulseaudio plugin; i know in any case that if i use 'hardware' it says 'resource busy' (because pulseaudio is already playing some kind of leftover sound through firefox, even though i can't hear anything...)
the problem is, that when i choose 'plug-in' i get a nasty crash. running in GDB gives the following:
snd_pcm_hw_params (input): Invalid argument input start failed : Input/output error pd: pcm.c:899: snd_pcm_status: Assertion `pcm && status' failed.
i've posted a bug report here: https://sourceforge.net/tracker/index.php?func=detail&aid=2469719&gr...
Hallo, Damian Stewart hat gesagt: // Damian Stewart wrote:
i'm running Pd vanilla 0.41-0 on Ubuntu Intrepid, and trying to get it to play nice with pulseaudio (setup as an alsa plugin) is proving difficult.
if i choose 'alsa', i have two options for devices, 'HDA Intel (hardware)' and 'HDA Intel (plug-in)'. I assume that 'plug-in' ought to connect through the pulseaudio plugin;
In ALSA terms, 'HDA Intel (hardware)' corresponds to the ALSA PCM "hw:0" assuming your Intel card is the first in the system. 'HDA Intel (plug-in)' in the same fashion corresponds to the ALSA PCM "plug:hw:0" or short "plughw:0". This device will be busy at the same time that hw:0 is busy, so you cannot use it either - although Pd should not crash of course.
To add additional, freely named ALSA PCMs to Pd's device dropdown list use the "-alsaadd" command line option. For example say you have a custom PCM defined in your .asoundrc like this:
pcm.custom {
type hw
card 1
}
ctl.custom {
type hw
card 1
}
Then you can start Pd like:
$ pd -alsa -alsaadd custom
to make a fifth device show up in Media->Audio Settings called "custom".
Ciao
Frank
Frank Barknecht wrote:
To add additional, freely named ALSA PCMs to Pd's device dropdown list use the "-alsaadd" command line option. For example say you have a custom PCM defined in your .asoundrc like this:
excellent! i think this has solved all my problems. thanks so much for the info.
i heart pulseaudio.
To add additional, freely named ALSA PCMs to Pd's device dropdown list use the "-alsaadd" command line option. For example say you have a custom PCM defined in your .asoundrc like this:
hi, I have a pcm.quattro device defined in .asoundrc which bind 2 stereo devices to allow quad sound. And I can even get it to work(*). But:
When I try to add it to pd it is only listed in the input devices: $ pd -alsa -alsaadd quattro -listdev
input devices:
- USB Audio Quattro (hardware)
- USB Audio Quattro (plug-in)
- HDA Intel (hardware)
- HDA Intel (plug-in)
- quattro
output devices:
- USB Audio Quattro (hardware)
- USB Audio Quattro (plug-in)
- HDA Intel (hardware)
- HDA Intel (plug-in)
When I try to actually use it it fails with: output snd_pcm_delay failed: Input/output error astate 0 audio I/O stuck... closing audio
SImilarly when I try with: -audioin 3 audioout 5
Somehow pd doesn't like it, any ideas why?
thanks Oded
(*) I am able to use the quattro device to play quad sound with clm/snd. No problems there. Sound playback is with sndplay and by setting MUS_ALSA_DEVICE=quattro it works.
-
Claude Heiland-Allen -
Damian Stewart -
Frank Barknecht -
Oded Ben-Tal -
volker böhm