Re: [PD] installing latest pd vanilla on RPI

2014-07-18 Thread Alexandre Torres Porres via Pd-list
"RPis are not very powerful, and running them without a desktop (using ssh or
similar over ethernet and /etc/rc.local to launch stuff on boot) makes a
lot of sense."

are you saying it basically doesn't really work for live audio applications
with the desktop system on and all?

cause, yeah, it seems it can'thandle, but I always thought you guys were
doing it with the desktop system and everything

I just got into this for curiosity, I don't really need a RPi for anything,
just wanted to play with it and see if it could run simple patches. I could
eventually use it live, but it wouldn't make sense to run it over ssh with
another computer (would rather just use the other computer).

cheers


2014-07-04 3:34 GMT-03:00 Simon Wise via Pd-list :

> On 03/07/14 22:55, Alexandre Torres Porres via Pd-list wrote:
>
>> Hi IOhannes, I read your other answer giving more info on why it could be
>> outdated even if released a couple of weeks ago. I think I get, although
>> I'd still assume or don't see why pd wouldn't be available at "apt-get" if
>> it were up to date.
>>
>
> The meaning of 'stable' in debian is that it does not change, and apt-get
> fetches packages that you wish to install from this base (it would be
> possible for someone to maintain the latest pd as a raspbian package, but
> it is almost as easy to install from Millers site so no-one bothers ... the
> fact that pd is in debian means it gets tested on ARM and the version in
> 'stable' automatically gets built as part of raspbian with no extra work,
> which was especially nice when raspbian first came out). This system allows
> distributions like raspbian to have a predictable base that they can then
> take the time required to adapt for their purposes, and it allows sites
> like Millers to build the up-to-date versions within that known framework
> so that they 'just work' (and will still work a few weeks later) because
> all the stuff it depends on does not keep changing versions every day.
>
> In the case of raspbian they have compiled debian with lots of
> modifications to suit their particular CPU and have added and keep working
> on lots of extra stuff that is specifically for their GPU and peripherals
> etc. They then maintain raspbian with all these added things updated from
> time to time but staying with 'stable' as the base. Presumably they will
> move to jessie sometime for their main version (probably not till they get
> it tested and running cleanly sometime after it is 'frozen' in advance of
> it becoming the new stable ... this freeze would be expected reasonably
> soon, debian does this on a two year cycle). But that does involve lots of
> work and lots of testing since they are building the whole of debian for an
> architecture which is halfway between the two official debian architectures
> (the CPU is a rather old version of ARM, but with floating point hardware).
> Chasing all the changes in the latest versions of everything all the time
> would be very hard work.
>
> As for menus or desktop icons ... it is just a little text file called
> "puredata.desktop" containing something like:
>
> [Desktop Entry]
> Name=Pure Data
> Comment=Visual dataflow programming platform for multimedia
> Comment[ca]=Plataforma de programació visual per aplicacions multimèdia
> Comment[de]=Grafische Datenflussprogrammierung für Multimedia
> Comment[es]=Plataforma de programación visual para aplicaciones multimedia
> Comment[fr]=Plateforme de programmation visuelle pour applications
> multimédia
> Comment[it]=Piattaforma di programmazione visuale per applicazioni
> multimedia
> Comment[pt]=Plataforma de programação visuais para multimedia
> Exec=pd -noadc %F
> Terminal=false
> Type=Application
> Icon=puredata.xpm
> Categories=AudioVideo;Audio;Video;Development
> MimeType=text/x-puredata;application/x-maxmsp;text/x-maxmsp;
> StartupNotify=false
>
> using the appropriate "Exec=" line, and an appropriate file for "Icon="
>
> if you add this file to the folder "/usr/share/applications" then it
> should turn up in menus, or if you put it on the desktop it should show up
> as an icon you can drag and drop to.
>
>
> But the RPis are not very powerful, and running them without a desktop
> (using ssh or similar over ethernet and /etc/rc.local to launch stuff on
> boot) makes a lot of sense.
>
> Simon
>
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
> listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] [lop~] coefficient calculation

2014-07-18 Thread Alexandre Torres Porres via Pd-list
It's been noted that [vcf~] can be obtained with a [cpole~] object - though
I didn't do it yet as I find it a bit hard to get to the coeficients from
the vcf~ code.

Anyway, if you can get it with a [cpole~] object, it means you could do it
with [biquad~] coeficients, right? I suppose so, but then, how exactly? I
mean, if I have the coeficients of [cpole~], how do I get to [biquad~]'s?

maybe this will help getting biquad's coefficients from [vcf~]'s
parameters... maybe not, I don't know, I need help :)

thanks


2014-07-19 0:44 GMT-03:00 Alexandre Torres Porres :

> hi all, I've been working on filter patches for my courses and I'm still
> failing ti get biquad coeficients from the [vcf~] code. Maybe anyone out
> there could help?
>
> I wanted this to plot the frequency response in realtime...
>
> the [vcf~] filters aren't in the audio Audio-EQ-Cookbook, and the code
> looks a bit too complicated
>
> thanks
>
>
> 2014-05-26 10:23 GMT-03:00 Joe White :
>
> Ahh yes of course thanks Frank!
>>
>> Have you guys checked out this paper on 'High-Order Digital Parametric
>> Equalizer Design '?
>> Apparently it reduces the need to cascade filter implementations to achieve
>> high orders.
>>
>> Cheers,
>> Joe
>>
>>
>> On 24 May 2014 09:53, Frank Barknecht  wrote:
>>
>>> Hi Joe,
>>>
>>> versions of these calculations without [expr] are also part of the
>>> rj-library as u_lowpass, u_lowpassq etc. These have been taken straight
>>> from the Audio-EQ-Cookbook.
>>>
>>> Ciao
>>> --
>>> Frank
>>>
>>> On Fri, May 23, 2014 at 12:06:45PM +0100, Joe White wrote:
>>> > Thanks for the abstractions Chris. Am I correct in thinking the
>>> licensing
>>> > issues for [expr] have been resolved now?
>>> >
>>> > Cheers,
>>> > Joe
>>> >
>>> >
>>> > On 21 May 2014 23:22, Chris Clepper  wrote:
>>> >
>>> > > On Wed, May 21, 2014 at 5:31 PM, Joe White 
>>> wrote:
>>> > >
>>> > >>
>>> > >>
>>> > >> Is it intentional to not a bank of go-to filters? [biquad~] is the
>>> next
>>> > >> one I would go to, but generating your own coefficients isn't
>>> that... err..
>>> > >> efficient when you're wanting some that just 'works' :)
>>> > >>
>>> > >>
>>> > > Attached are a set of abstractions wrapping most of the 'Audio EQ
>>> > > Cookbook' formulae around biquad~.  It would be nice for Pd to
>>> include
>>> > > something like this.
>>> > >
>>> > > The only drawback to [biquad~] is it doesn't take audio rate
>>> coefficients.
>>> > >  There are of course externals that do audio rate for cutoff, Q, etc.
>>> > >
>>> > > Chris
>>> > >
>>> > >
>>> > >>
>>> > >>
>>> > >> On 21 May 2014 17:31, Miller Puckette  wrote:
>>> > >>
>>> > >>> Hi Joe -
>>> > >>>
>>> > >>> That code is an approximation that works well for low cutoff
>>> > >>> frequencies but badly for high ones.  (I should probably warn
>>> > >>> about this in the help window... that'll go on my dolist)
>>> > >>>
>>> > >>> cheers
>>> > >>> M
>>> > >>>
>>> > >>>
>>> > >>> On Fri, May 16, 2014 at 12:58:31PM +0100, Joe White wrote:
>>> > >>> > Hi,
>>> > >>> >
>>> > >>> > I've been looking at the [lop~] implementation (Pd-0.45-4) and
>>> noticed
>>> > >>> > something that seem weird to me.
>>> > >>> >
>>> > >>> > In d_filter, line 176:
>>> > >>> >
>>> > >>> > static void siglop_ft1(t_siglop *x, t_floatarg f)
>>> > >>> > {
>>> > >>> > if (f < 0) f = 0;
>>> > >>> > x->x_hz = f;
>>> > >>> > x->x_ctl->c_coef = f * (2 * 3.14159) / x->x_sr;
>>> > >>> > if (x->x_ctl->c_coef > 1)
>>> > >>> > x->x_ctl->c_coef = 1;
>>> > >>> > else if (x->x_ctl->c_coef < 0)
>>> > >>> > x->x_ctl->c_coef = 0;
>>> > >>> > }
>>> > >>> >
>>> > >>> >
>>> > >>> > Is it correct that for:
>>> > >>> >
>>> > >>> > y[n] = x[n] * a + y[n-1] * b
>>> > >>> >
>>> > >>> > *a = 2π * Fc / Fs*
>>> > >>> > b = 1.0 - a
>>> > >>> >
>>> > >>> > where Fc is the cut-off frequency and Fs the sampling frequency.
>>> > >>> >
>>> > >>> > I appreciate the a coefficient is bounded afterwards but
>>> wouldn't that
>>> > >>> mean
>>> > >>> > that Fc values greater than Fs / 2π will have no impact on the
>>> sound
>>> > >>> being
>>> > >>> > processed.
>>> > >>> >
>>> > >>> > For example if Fs is 44100, then Fc values above ~7020Hz will not
>>> > >>> affect
>>> > >>> > the filter.
>>> > >>> >
>>> > >>> > Have I missed something crucial or could this a bug in the code?
>>> > >>> >
>>> > >>> > The simple IIR filter described in
>>> > >>> > http://en.wikipedia.org/wiki/Low-pass_filter suggests that the
>>> actual
>>> > >>> > coefficient calculation should be more like:
>>> > >>> >
>>> > >>> > a = 2π*Fc / (2π*Fc + Fs)
>>> > >>> >
>>> > >>> > Looking forward to understand this more!
>>> > >>> >
>>> > >>> > Cheers,
>>> > >>> > Joe
>>> > >>> >
>>> > >>> > --
>>> > >>> > Follow me on Twitter @diplojocus
>>> > >>>
>>> > >>> > ___
>>> > >>> > Pd-list@lists.iem.at mailing list
>>> > >>> > UNSUBSCRIBE and account-management ->
>>> > >>> http://list

Re: [PD] [lop~] coefficient calculation

2014-07-18 Thread Alexandre Torres Porres via Pd-list
hi all, I've been working on filter patches for my courses and I'm still
failing ti get biquad coeficients from the [vcf~] code. Maybe anyone out
there could help?

I wanted this to plot the frequency response in realtime...

the [vcf~] filters aren't in the audio Audio-EQ-Cookbook, and the code
looks a bit too complicated

thanks


2014-05-26 10:23 GMT-03:00 Joe White :

> Ahh yes of course thanks Frank!
>
> Have you guys checked out this paper on 'High-Order Digital Parametric
> Equalizer Design '?
> Apparently it reduces the need to cascade filter implementations to achieve
> high orders.
>
> Cheers,
> Joe
>
>
> On 24 May 2014 09:53, Frank Barknecht  wrote:
>
>> Hi Joe,
>>
>> versions of these calculations without [expr] are also part of the
>> rj-library as u_lowpass, u_lowpassq etc. These have been taken straight
>> from the Audio-EQ-Cookbook.
>>
>> Ciao
>> --
>> Frank
>>
>> On Fri, May 23, 2014 at 12:06:45PM +0100, Joe White wrote:
>> > Thanks for the abstractions Chris. Am I correct in thinking the
>> licensing
>> > issues for [expr] have been resolved now?
>> >
>> > Cheers,
>> > Joe
>> >
>> >
>> > On 21 May 2014 23:22, Chris Clepper  wrote:
>> >
>> > > On Wed, May 21, 2014 at 5:31 PM, Joe White 
>> wrote:
>> > >
>> > >>
>> > >>
>> > >> Is it intentional to not a bank of go-to filters? [biquad~] is the
>> next
>> > >> one I would go to, but generating your own coefficients isn't
>> that... err..
>> > >> efficient when you're wanting some that just 'works' :)
>> > >>
>> > >>
>> > > Attached are a set of abstractions wrapping most of the 'Audio EQ
>> > > Cookbook' formulae around biquad~.  It would be nice for Pd to include
>> > > something like this.
>> > >
>> > > The only drawback to [biquad~] is it doesn't take audio rate
>> coefficients.
>> > >  There are of course externals that do audio rate for cutoff, Q, etc.
>> > >
>> > > Chris
>> > >
>> > >
>> > >>
>> > >>
>> > >> On 21 May 2014 17:31, Miller Puckette  wrote:
>> > >>
>> > >>> Hi Joe -
>> > >>>
>> > >>> That code is an approximation that works well for low cutoff
>> > >>> frequencies but badly for high ones.  (I should probably warn
>> > >>> about this in the help window... that'll go on my dolist)
>> > >>>
>> > >>> cheers
>> > >>> M
>> > >>>
>> > >>>
>> > >>> On Fri, May 16, 2014 at 12:58:31PM +0100, Joe White wrote:
>> > >>> > Hi,
>> > >>> >
>> > >>> > I've been looking at the [lop~] implementation (Pd-0.45-4) and
>> noticed
>> > >>> > something that seem weird to me.
>> > >>> >
>> > >>> > In d_filter, line 176:
>> > >>> >
>> > >>> > static void siglop_ft1(t_siglop *x, t_floatarg f)
>> > >>> > {
>> > >>> > if (f < 0) f = 0;
>> > >>> > x->x_hz = f;
>> > >>> > x->x_ctl->c_coef = f * (2 * 3.14159) / x->x_sr;
>> > >>> > if (x->x_ctl->c_coef > 1)
>> > >>> > x->x_ctl->c_coef = 1;
>> > >>> > else if (x->x_ctl->c_coef < 0)
>> > >>> > x->x_ctl->c_coef = 0;
>> > >>> > }
>> > >>> >
>> > >>> >
>> > >>> > Is it correct that for:
>> > >>> >
>> > >>> > y[n] = x[n] * a + y[n-1] * b
>> > >>> >
>> > >>> > *a = 2π * Fc / Fs*
>> > >>> > b = 1.0 - a
>> > >>> >
>> > >>> > where Fc is the cut-off frequency and Fs the sampling frequency.
>> > >>> >
>> > >>> > I appreciate the a coefficient is bounded afterwards but wouldn't
>> that
>> > >>> mean
>> > >>> > that Fc values greater than Fs / 2π will have no impact on the
>> sound
>> > >>> being
>> > >>> > processed.
>> > >>> >
>> > >>> > For example if Fs is 44100, then Fc values above ~7020Hz will not
>> > >>> affect
>> > >>> > the filter.
>> > >>> >
>> > >>> > Have I missed something crucial or could this a bug in the code?
>> > >>> >
>> > >>> > The simple IIR filter described in
>> > >>> > http://en.wikipedia.org/wiki/Low-pass_filter suggests that the
>> actual
>> > >>> > coefficient calculation should be more like:
>> > >>> >
>> > >>> > a = 2π*Fc / (2π*Fc + Fs)
>> > >>> >
>> > >>> > Looking forward to understand this more!
>> > >>> >
>> > >>> > Cheers,
>> > >>> > Joe
>> > >>> >
>> > >>> > --
>> > >>> > Follow me on Twitter @diplojocus
>> > >>>
>> > >>> > ___
>> > >>> > Pd-list@lists.iem.at mailing list
>> > >>> > UNSUBSCRIBE and account-management ->
>> > >>> http://lists.puredata.info/listinfo/pd-list
>> > >>>
>> > >>>
>> > >>
>> > >>
>> > >> --
>> > >> Follow me on Twitter @diplojocus
>> > >>
>> > >> ___
>> > >> Pd-list@lists.iem.at mailing list
>> > >> UNSUBSCRIBE and account-management ->
>> > >> http://lists.puredata.info/listinfo/pd-list
>> > >>
>> > >>
>> > >
>> >
>> >
>> > --
>> > Follow me on Twitter @diplojocus
>>
>> > ___
>> > Pd-list@lists.iem.at mailing list
>> > UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
>
> --
> Follow me on Twitter @diplojocus
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSU

[PD] PdDroidParty stops finding patches ...

2014-07-18 Thread R. Mattes via Pd-list
Hello list,

I just upgraded my Android (Toshiba AC100) to the latest CyanogenMod (Android
4.4.2 / CM 11) and updated PdDroidParty as well (PdDroidParty-debug-264.apk)
Srtangely, PdDroidParty can't find any of my Patches any more (same goes for
the example pathes). Any idea what's going on?

 Cheers, Ralf Mattes 


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list