Re: [PD] keeping Pd DSP alive
There isn't a way to poll the DSP state in Pd Vanilla. -Jonathan On Saturday, April 12, 2014 8:47 PM, Chris Clepper wrote: [pdinfo] is not part of vanilla. I can't (nor want to) use extended for this project. On Saturday, April 12, 2014, Jonathan Wilkes wrote: On 04/12/2014 04:27 PM, Chris Clepper wrote: > >Hi list >> >> >>I'm wondering if there are any recommended ways to ensure DSP keeps running >>for long periods like permanent installations. I get 'audio I/O stuck' >>popping up every few days, which is not bad, but ideally audio should stay >>running indefinitely. >> >> >>I can send a [metro 1000] to [;pd DSP 1( to keep audio going, but is there >>any long term issue with doing that? Will it reliably restart audio after Pd >>closes it? >> >> >>Also, the internal message [;pd audiostate( only returns data to the console. >> Perhaps there is a way to poll Pd for the internal DSP state and restart it >>if it dies? >In Pd-l2ork: >[dsp-status( >| >[pdinfo] > >-Jonathan > > > >> >>Thanks! >> >> >> >> >>___ 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
Re: [PD] keeping Pd DSP alive
[pdinfo] is not part of vanilla. I can't (nor want to) use extended for this project. On Saturday, April 12, 2014, Jonathan Wilkes wrote: > On 04/12/2014 04:27 PM, Chris Clepper wrote: > > Hi list > > I'm wondering if there are any recommended ways to ensure DSP keeps > running for long periods like permanent installations. I get 'audio I/O > stuck' popping up every few days, which is not bad, but ideally audio > should stay running indefinitely. > > I can send a [metro 1000] to [;pd DSP 1( to keep audio going, but is > there any long term issue with doing that? Will it reliably restart audio > after Pd closes it? > > Also, the internal message [;pd audiostate( only returns data to the > console. Perhaps there is a way to poll Pd for the internal DSP state and > restart it if it dies? > > > In Pd-l2ork: > [dsp-status( > | > [pdinfo] > > -Jonathan > > > Thanks! > > > > ___pd-l...@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
Re: [PD] keeping Pd DSP alive
I think the metronome solution will work - if DSP is already on the message has no effect, so this will only act to re-start hung-up audio. Just curious - what OS/hardware is giving you the "audio stuck" messages? They shouldn't be happening at all. cheers Miller On Sat, Apr 12, 2014 at 04:27:02PM -0400, Chris Clepper wrote: > Hi list > > I'm wondering if there are any recommended ways to ensure DSP keeps running > for long periods like permanent installations. I get 'audio I/O stuck' > popping up every few days, which is not bad, but ideally audio should stay > running indefinitely. > > I can send a [metro 1000] to [;pd DSP 1( to keep audio going, but is there > any long term issue with doing that? Will it reliably restart audio after > Pd closes it? > > Also, the internal message [;pd audiostate( only returns data to the > console. Perhaps there is a way to poll Pd for the internal DSP state and > restart it if it dies? > > Thanks! > ___ > 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
Re: [PD] keeping Pd DSP alive
On 04/12/2014 04:27 PM, Chris Clepper wrote: Hi list I'm wondering if there are any recommended ways to ensure DSP keeps running for long periods like permanent installations. I get 'audio I/O stuck' popping up every few days, which is not bad, but ideally audio should stay running indefinitely. I can send a [metro 1000] to [;pd DSP 1( to keep audio going, but is there any long term issue with doing that? Will it reliably restart audio after Pd closes it? Also, the internal message [;pd audiostate( only returns data to the console. Perhaps there is a way to poll Pd for the internal DSP state and restart it if it dies? In Pd-l2ork: [dsp-status( | [pdinfo] -Jonathan Thanks! ___ 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
[PD] keeping Pd DSP alive
Hi list I'm wondering if there are any recommended ways to ensure DSP keeps running for long periods like permanent installations. I get 'audio I/O stuck' popping up every few days, which is not bad, but ideally audio should stay running indefinitely. I can send a [metro 1000] to [;pd DSP 1( to keep audio going, but is there any long term issue with doing that? Will it reliably restart audio after Pd closes it? Also, the internal message [;pd audiostate( only returns data to the console. Perhaps there is a way to poll Pd for the internal DSP state and restart it if it dies? Thanks! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] can [bp~] be obtained with biquad coefficients?
On Sam, 2014-04-12 at 03:45 -0300, Alexandre Torres Porres wrote: > > change the [fexpr~] to something like > > [fexpr~ $x[0] + ($f2 * $y[-1]) + ($f3 * $y[-2])] > > > f*ck, I'll be damned, now my patch that implements [bp~] with [fexpr~] > seems to work, it's attached. Thanks! That is great! I never really dug into that topic, but having it as a patch makes it more accessible I think, at least for me. Thanks for sharing. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [bp~] really equal to [vcf~]?
Yep - vcf~ is essentially a wrapper for cpole~. cheers M On Sat, Apr 12, 2014 at 02:10:19PM -0300, Alexandre Torres Porres wrote: > that's great to know, thanks! > > Let me just see if I get a bit of the theory. Can I get [vcf~] with just > one [cpole~] object and the right coeficients? > > Cheers > > > 2014-04-12 13:36 GMT-03:00 Miller Puckette : > > > They're quite different. bp~ is the cheapest possible bandpass filter > > (as far as I know). vcf~ is a one-pole complex filter whose outputs are > > the real and imaginry parts. The real part may be used as a resonant > > bandpass filter and the imaginary as a resonant low-pass filter, but > > they can be combined to make other possibilities. > > > > It's possible to graph their frequency responses using the help patch > > "H10.measurement.pd' in 3.audio.examples. > > > > cheers > > Miller > > > > On Sat, Apr 12, 2014 at 04:28:11AM -0300, Alexandre Torres Porres wrote: > > > Hi there, who can confirm that both [bp~] and [vcf~] are exactly the > > really > > > same thingy? The code looks quite different... > > > > > > Moreover, why the two outlets for vcf~? Help doesn't say anything. > > > > > > Thanks > > > > > ___ > > > 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
Re: [PD] [bp~] really equal to [vcf~]?
that's great to know, thanks! Let me just see if I get a bit of the theory. Can I get [vcf~] with just one [cpole~] object and the right coeficients? Cheers 2014-04-12 13:36 GMT-03:00 Miller Puckette : > They're quite different. bp~ is the cheapest possible bandpass filter > (as far as I know). vcf~ is a one-pole complex filter whose outputs are > the real and imaginry parts. The real part may be used as a resonant > bandpass filter and the imaginary as a resonant low-pass filter, but > they can be combined to make other possibilities. > > It's possible to graph their frequency responses using the help patch > "H10.measurement.pd' in 3.audio.examples. > > cheers > Miller > > On Sat, Apr 12, 2014 at 04:28:11AM -0300, Alexandre Torres Porres wrote: > > Hi there, who can confirm that both [bp~] and [vcf~] are exactly the > really > > same thingy? The code looks quite different... > > > > Moreover, why the two outlets for vcf~? Help doesn't say anything. > > > > Thanks > > > ___ > > 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
Re: [PD] [bp~] really equal to [vcf~]?
They're quite different. bp~ is the cheapest possible bandpass filter (as far as I know). vcf~ is a one-pole complex filter whose outputs are the real and imaginry parts. The real part may be used as a resonant bandpass filter and the imaginary as a resonant low-pass filter, but they can be combined to make other possibilities. It's possible to graph their frequency responses using the help patch "H10.measurement.pd' in 3.audio.examples. cheers Miller On Sat, Apr 12, 2014 at 04:28:11AM -0300, Alexandre Torres Porres wrote: > Hi there, who can confirm that both [bp~] and [vcf~] are exactly the really > same thingy? The code looks quite different... > > Moreover, why the two outlets for vcf~? Help doesn't say anything. > > Thanks > ___ > 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
Re: [PD] can [bp~] be obtained with biquad coefficients?
there are incremnents to do still, but thanks :)
2014-04-12 9:25 GMT-03:00 patrice colet :
>
> Le 12/04/2014 08:45, Alexandre Torres Porres a écrit :
>
> > change the [fexpr~] to something like
> > [fexpr~ $x[0] + ($f2 * $y[-1]) + ($f3 * $y[-2])]
>
> f*ck, I'll be damned, now my patch that implements [bp~] with [fexpr~]
> seems to work, it's attached. Thanks!
>
>
> thanks for the share, when I tried to implement filters with expr and
> biquad I haven't been able to get it working fully (some clics appeared
> when changing frequency)... Your implementation works very well in both
> cases, "chapeau bas"
>
>
> > it's pretty easy to see that from the code you quoted
>
> I can't really see it from the code itself. And, well, remember I
> mentioned about the biquad code?
>
> {
> t_sample output = *in++ + fb1 * last + fb2 * prev;
> if (PD_BIGORSMALL(output))
> output = 0;
> *out++ = ff1 * output + ff2 * last + ff3 * prev;
> prev = last;
> last = output;
> }
>
> Well, I made a silly confusion mistake and thought the first line was
> feedforward (and then equivalent to the bp~). But still, it could be it
> for all I can tell. How can you actually see wether is feedback or not?
>
> Anyway, the patch works and I can also make it on biquad, it's all
> attached.
>
> > after all it's a resonating filter and therefore needs a feedback path.
>
> I wouldn't know about that, but that's how you convinced me you knew
> what you were talking about :)
>
> Thanks again
>
>
> 2014-04-11 16:46 GMT-03:00 volker böhm :
>
>>
>> On 11.04.2014, at 16:48, Alexandre Torres Porres wrote:
>>
>> > ""last" and "prev" are the last two _output_ samples.
>> > i don't know fexpr~ very well, but it looks like you try to access the
>> last _input_ samples."
>> >
>> > In [fexpr~] you can access input samples with $x variables and output
>> samples with $y. So you're correct. I'm going for the input samples.
>> >
>> > But I did it because I believe "last" and "prev" in this formula are in
>> fact about input samples.
>>
>>
>> no, and it's pretty easy to see that from the code you quoted:
>>
>> > > t_sample output = *in++ + coef1 * last + coef2 * prev;
>> > >
>> > > *out++ = gain * output;
>> > >
>> > > prev = last;
>> > >
>> > > last = output;
>>
>>
>> after all it's a resonating filter and therefore needs a feedback path.
>> so it somehow has to take outgoing samples back in.
>>
>>
>> > So I feel pretty strong about getting this [fexpr~] right. Is there
>> anything I did not take into consideration?
>>
>> yes, calculate coef1, coef2 and gain by using the formulas from the code,
>> change the [fexpr~] to something like [ fexpr~ $x[0] + ($f2 * $y[-1]) +
>> ($f3 * $y[-2]) ],
>> (where $f2 and $f3 would be coef1 and coef2 resp.)
>> apply the gain factor afterwards,
>> and you are done.
>>
>> vb
>>
>>
>>
>>
>
>
> ___pd-l...@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
Re: [PD] can [bp~] be obtained with biquad coefficients?
Le 12/04/2014 08:45, Alexandre Torres Porres a écrit :
> change the [fexpr~] to something like
> [fexpr~ $x[0] + ($f2 * $y[-1]) + ($f3 * $y[-2])]
f*ck, I'll be damned, now my patch that implements [bp~] with [fexpr~]
seems to work, it's attached. Thanks!
thanks for the share, when I tried to implement filters with expr and
biquad I haven't been able to get it working fully (some clics appeared
when changing frequency)... Your implementation works very well in both
cases, "chapeau bas"
> it's pretty easy to see that from the code you quoted
I can't really see it from the code itself. And, well, remember I
mentioned about the biquad code?
{
t_sample output = *in++ + fb1 * last + fb2 * prev;
if (PD_BIGORSMALL(output))
output = 0;
*out++ = ff1 * output + ff2 * last + ff3 * prev;
prev = last;
last = output;
}
Well, I made a silly confusion mistake and thought the first line was
feedforward (and then equivalent to the bp~). But still, it could be
it for all I can tell. How can you actually see wether is feedback or not?
Anyway, the patch works and I can also make it on biquad, it's all
attached.
> after all it's a resonating filter and therefore needs a feedback path.
I wouldn't know about that, but that's how you convinced me you knew
what you were talking about :)
Thanks again
2014-04-11 16:46 GMT-03:00 volker böhm >:
On 11.04.2014, at 16:48, Alexandre Torres Porres wrote:
> ""last" and "prev" are the last two _output_ samples.
> i don't know fexpr~ very well, but it looks like you try to
access the last _input_ samples."
>
> In [fexpr~] you can access input samples with $x variables and
output samples with $y. So you're correct. I'm going for the input
samples.
>
> But I did it because I believe "last" and "prev" in this formula
are in fact about input samples.
no, and it's pretty easy to see that from the code you quoted:
> > t_sample output = *in++ + coef1 * last + coef2 * prev;
> >
> > *out++ = gain * output;
> >
> > prev = last;
> >
> > last = output;
after all it's a resonating filter and therefore needs a feedback
path.
so it somehow has to take outgoing samples back in.
> So I feel pretty strong about getting this [fexpr~] right. Is
there anything I did not take into consideration?
yes, calculate coef1, coef2 and gain by using the formulas from
the code,
change the [fexpr~] to something like [ fexpr~ $x[0] + ($f2 *
$y[-1]) + ($f3 * $y[-2]) ],
(where $f2 and $f3 would be coef1 and coef2 resp.)
apply the gain factor afterwards,
and you are done.
vb
___
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
[PD] [PD-announce] jmmmp abstractions update
Hello everyone, the jmmmp library of abstractions has been updated. Besides minor changes, the new objects have been added: bezier~ - Transfer function GUI with one cubic bézier curve at audio rate matrixctrl - GUI for [iemmatrix/mtx_mul~] swatch-gui - Pick a color for your GUI using the hue-saturation chart (including color numbers for data structures) Feel free to download it and try it out. Hopefully the new version of Pd-Extended will have this library with it. For more informations and a tarball file, go to https://puredata.info/downloads/jmmmp/releases/0.3 Best, jmmmp ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Pd and jack.osc
Hi! I'm trying to interface Pure Data with jack.osc, but I think I'm missing something At the moment I can connect Pure Data to jack.osc and I've successfully registered the PD client to jack.osc server. I've also successfully executed the "/connect" and "/locate" messages, but I'm having troubles understanding the "/receive" and "/receive_at". The man page (http://rd.slavepianos.org/?t=rju&m=jack-osc.text) says that I must specify a "category" that is a: "bit mask that indicates what categories of notification packets are requested." I've tried in many ways, but it seems that I'm not be able to create the correct OSC message. -- Nicola ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] [bp~] really equal to [vcf~]?
Hi there, who can confirm that both [bp~] and [vcf~] are exactly the really same thingy? The code looks quite different... Moreover, why the two outlets for vcf~? Help doesn't say anything. Thanks ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
