Re: [PD] C externals in M1 give errors

[Chris Clepper]

That issue only relates to data corruption in the case of major failures
like power loss and kernel panics.  In most of those situations some data
loss is not only expected but also the least of your concerns.

As for the original topic, the first thing to check is the usual problems
moving between architectures like endianess, definition of data structures
(is long really 32 bits, double 64 bits, etc), memory alignment and
compiler settings.  Does the code work with all of the optimizations turned
off?

On Fri, Aug 12, 2022 at 5:58 AM Bastiaan van den Berg 
wrote:

> Did you read that M1's storage has so much cache + lies to the OS about
> cache commitments, leading to data corruption sometimes?
> https://twitter.com/marcan42/status/1494213855387734019
>
> On Fri, Aug 12, 2022 at 6:14 AM Jaime Oliver 
> wrote:
>
>> Dear all,
>>
>> I have a c external that compiles and runs fine on windows, Linux, and
>> Mac Intel systems, but while the exact same code compiles ok on a Mac M1
>> system, it runs with errors.
>>
>> I am trying to figure out the bug, but wonder if anyone has come across
>> something like this? The external itself is not particularly complex. It
>> writes and reads text files, does basic arithmetic, and uses arrays of
>> various sizes.
>>
>> Does anyone have any suggestions of where to look first?
>>
>> Best,
>>
>> Jaime
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
>>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] shmem and bigger buffer size

[Chris Clepper]

MacOS used to have absurdly small values for the max SHMEM in the kernel.
Not sure about the current state of the defaults though.  Check posts like
these for how to adjust:

http://flummox-engineering.blogspot.com/2014/05/increasing-shared-memory-for-os-x.html

I think there is also something in the GEM docs for setting up pix_share
since that needs a lot of shared memory space for HD video frames.

On Fri, Jan 31, 2020 at 7:59 AM cyrille henry  wrote:

> I don't know why it fail on mac. You can try to split in smaller table,
> like you suggested.
> But you should also test it on linux first since it's your main target.
>
> c
>
> Le 30/01/2020 à 19:55, iftah gabbai a écrit :
> > im building on mac os 10.12 and intending to run on linux(arm), i
> haven’t tested on linux, the problems im having are on mac,
> >
> > thanks!
> >
> > On Thu 30. Jan 2020 at 17:47, cyrille henry  c...@chnry.net>> wrote:
> >
> > what is your OS?
> >
> > Le 30/01/2020 à 17:10, iftah gabbai a écrit :
> >  > hey C, i have 16gb of ram, and if i did not completely messed up
> my calcs i tried to allocate 2 min of 96khz (11.520.000)
> >  >
> >  > thanks again!
> >  >
> >  > On Thu 30. Jan 2020 at 17:06, cyrille henry   >> 
> wrote:
> >  >
> >  > hello,
> >  >
> >  > Do you have enough free memory on your computer?
> >  > I just test on y computer, I can reproduce this error as soon
> as I ask an allocation bigger than the available memory on my hardware.
> >  > (between 500 000 000 and 1 000 000 000 points)
> >  >
> >  > cheers
> >  > Cyrille
> >  >
> >  > Le 30/01/2020 à 12:11, iftah gabbai a écrit :
> >  >  > ...perhaps i should elaborate, im trying to dump an array
> in the size of 11 520 000(2 min of 96 khz audio) to another instance of PD,
> is it possible at all or do i have to break it to smaller chunks?
> >  >  >
> >  >  > On Thu, Jan 30, 2020 at 12:01 PM iftah gabbai <
> ift@gmail.com   >   wrote:
> >  >  >
> >  >  > hello all, ive been experimenting with shmem (the
> latest one i could find in deken), it works fine as long as i use very
> small arrays, as soon as i try to use bigger arrays ( havent checked where
> the breakpoint is but more than approx 40) it doesnt and it returns
> "could not allocate shmem memory Id"
> >  >  >
> >  >  > i wonder if im doing something wrong or if its a known
> thing?
> >  >  >
> >  >  >
> >  >  > thanks!
> >  >  >
> >  >  >
> >  >  > ___
> >  >  > Pd-list@lists.iem.at 
> > mailing list
> >  >  > UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
> >  >  >
> >  >
> >  >
> >  >
> >  > ___
> >  > Pd-list@lists.iem.at   Pd-list@lists.iem.at > mailing list
> >  > UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
> >  >
> >  >
> >  > ___
> >  > Pd-list@lists.iem.at  mailing list
> >  > UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
> >  >
> >
> >
> >
> > ___
> > Pd-list@lists.iem.at  mailing list
> > UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
> >
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] multiprocessing for GEM

[Chris Clepper]

I wrote pix_share_read/write exactly for this purpose.  It only moves pixes
between processes but that is the heavy CPU load most of the time.
Multiple GEM instances can read from the same write (or at least did when I
used it), so one GEM could capture from a video source, another compress
the image to disk and a third instance display it on screen.

On Thu, Oct 31, 2019 at 11:37 AM Csaba Láng  wrote:

> Hi dearest list,
>
> I am looking for a multiprocessing solution for GEM itself.
> What I found from Miller's paper:
> http://www.pdpatchrepo.info/hurleur/multiprocessing.pdf
> clearly deals with only audio multiprocessing as the object pd~ indicates
> its usage.
> Is there any method to spread GEM calculations among 4-8 processors?
>
> Best,
>
> Popesz
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] do we need externals for ARMv8 in raspberry pi 3 and 4?

[Chris Clepper]

The major difference for ArmV8 is the 64 bit address space, but the chips
are 100% compatible with v7 and before.  The only potential benefit of v8
for Pd would be the NEON instructions which are 128 bit wide vs 64 on v7.
Of course someone would have to write that NEON code first...

On Thu, Jun 27, 2019 at 2:09 PM Max  wrote:

> On 26.06.19 05:00, Alexandre Torres Porres wrote:
> > Hi, I just realized raspberry pi 3 and the new 4 are armv8... do they
> > need or benefit from an armv8 compile?
> >
> > So far I've only compiled for armv7, and it seems it could do just well
> > with armv6 (which is needed for raspberry pi zero)
>
> just earlier today I wanted to install timbreID on a raspberry through
> deken. It was hidden by default because the binary is for armv7 so
> considered a "foreign architecture" because the Raspberry 3 is armv8. I
> installed the armv7 and it seemed to be working.
>
> m.
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Help with reverb design and vanilla's abstractions ([rev1~]/[rev2~]/[rev3~])

[Chris Clepper]

There are no good references for designing reverbs because the info falls
under 'Trade Secrets' in the audio industry.  I develop commercial reverbs
and other effects as part of my job and can give you a few tips:

- FDN is not used in any of the 'classic' reverb designs (Concert Hall,
Plate, Chamber, etc).  Eventide did start to use it in the late 80s, but
their most famous reverb is not FDN based at all.  A number of plugins and
devices do use FDN now mostly for 'Room' type algorithms.
- The few patents for old reverb boxes are not very useful because they
leave out all of the 'secret sauce'.
- Modulation is where the magic happens.
- Andy's on to something with investigating mathematical sequences and
ratios
- Interpolation.  When to do it and how to do it is also key.
- Filters.  what type and where to use them
- Phase.  Relates to filters and interpolation and creates some surprising
results when used well.
- Move to Boston.  Almost all of the major reverb developments where done
here:  Blesser(EMT/Lexicon), David G(Lexicon), Chris Moore(Ursa Major),
 Bill Gardner and so on.  I think Miller even wrote the FDN paper at MIT.

Chris

On Wed, Feb 6, 2019 at 8:26 PM Alexandre Torres Porres 
wrote:

> Hi, I've read miller's book and I've always wanted to know a bit more
> about reverbs. I also want to better explain these examples to my students.
> One thing I wonder is about the choice of delay lengths for the early
> reflections and also for the recirculating delay lines. They seem quite
> arbitrary, right?
>
> All I could make of it is that these numbers are just broken down so they
> don't become multiples of each other, resulting in a rather complex mesh of
> reflection times.
>
> But also, it seems that a "room size" parameter can be controlled by the
> size of the delay lines, right?
>
> Anyway, I'd appreciate if I could learn more about these abstractions and
> also some cool references for study (such as "digital reverb modelling for
> dummies").
>
> cheers
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] (GEM) running pix_film without installing quicktime?

[Chris Clepper]

The basic DirectShow should support a few codecs - mostly WMV though.  If
you can install ffmpeg or similar the codec support will be much improved.

On Thu, Nov 29, 2018 at 12:59 PM enrike  wrote:

> On this machine I am testing now I have the standard desktop. I am
> running windows 7. I think the machines in the lab are the same
>
>
> 18/11/29 16:22(e)an, Chris Clepper igorleak idatzi zuen:
> > You have DirectShow support which can load video.  Make sure the
> > Aero/Metro/etc is turned off and you have the 'Standard Desktop' only.
> >
> > DirectShow is far better on Windows than Quicktime too.
> >
> > On Thu, Nov 29, 2018 at 3:19 AM enrike  > <mailto:alte...@gmail.com>> wrote:
> >
> >
> >  >> ok but do I need to install those codecs or can I just drop a dll
> >  >> inside GEM?
> >  >
> >  > i don't think so ...
> >  >
> >  >
> >  > just out of curiosity: can you playback this ?
> >  >
> >  >
> >
> http://klingt.org/fileservice/downloads/05826154340905930-test2_cut.zip
> >  >
> >  > (that's a simple 2 seconds mjpeg file encoded with FFMPEG.)
> >
> > I will try in the evening in the class computers but at home I have a
> > clean windows 7 install in an old machine. I tried there but does not
> > play the video you sent. In the PD console I get this
> >
> > filmQT: Could not initialize quicktime: error -2093
> >
> > [pix_movie]: DirectShow support
> >
> > [pix_movie]: opening
> >
>  
> C:/Users/r2d2/Desktop/malinette-soft-win-master/malinette-soft-win-master/malinette-ide/projects/malinette-default/test2_cut.avi
> >
> > with format 1908
> >
> > Unable to connect filters -2147220969
> >
> > [pix_movie]: unable to open file:
> >
>  
> C:/Users/r2d2/Desktop/malinette-soft-win-master/malinette-soft-win-master/malinette-ide/projects/malinette-default/test2_cut.avi
> >
> >
> >
> >
> > ___
> > Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list
> > UNSUBSCRIBE and account-management ->
> > https://lists.puredata.info/listinfo/pd-list
> >
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] (GEM) running pix_film without installing quicktime?

[Chris Clepper]

You have DirectShow support which can load video.  Make sure the
Aero/Metro/etc is turned off and you have the 'Standard Desktop' only.

DirectShow is far better on Windows than Quicktime too.

On Thu, Nov 29, 2018 at 3:19 AM enrike  wrote:

>
> >> ok but do I need to install those codecs or can I just drop a dll
> >> inside GEM?
> >
> > i don't think so ...
> >
> >
> > just out of curiosity: can you playback this ?
> >
> > http://klingt.org/fileservice/downloads/05826154340905930-test2_cut.zip
> >
> > (that's a simple 2 seconds mjpeg file encoded with FFMPEG.)
>
> I will try in the evening in the class computers but at home I have a
> clean windows 7 install in an old machine. I tried there but does not
> play the video you sent. In the PD console I get this
>
> filmQT: Could not initialize quicktime: error -2093
>
> [pix_movie]: DirectShow support
>
> [pix_movie]: opening
> C:/Users/r2d2/Desktop/malinette-soft-win-master/malinette-soft-win-master/malinette-ide/projects/malinette-default/test2_cut.avi
>
> with format 1908
>
> Unable to connect filters -2147220969
>
> [pix_movie]: unable to open file:
>
> C:/Users/r2d2/Desktop/malinette-soft-win-master/malinette-soft-win-master/malinette-ide/projects/malinette-default/test2_cut.avi
>
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] (GEM) running pix_film without installing quicktime?

[Chris Clepper]

The last Windows build I put together back in the dark ages used DirectShow
and not Quicktime for all video - file playback and recording and live
video devices.  That is usually on Windows machines by default and I did
test it on Windows 10 earlier this year and it worked.

On Wed, Nov 28, 2018 at 3:19 PM enrike  wrote:

> > when does your class start?
> >
> > i think antoine is right... DLL's can just be put in the same directory
> > as executable.
> >
> > but can you even run an executable on the machines? deep freeze?
>
> the class is already happening. I cannot do anything that requires admin
> rights on those machines. It looks like I will have to apply the tech
> department to do it and wait
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Blackmagic Deck Link Duo + Gem

[Chris Clepper]

Looks like Anton made a Syphon external for GEM a few years ago:

https://github.com/Syphon/PureData/releases/

Is he still on this mailing list?

On Sat, Jul 7, 2018 at 10:53 AM, Py Fave  wrote:

> Hello
>
> i had some results using spout with blackspout
>
> on windows
>
> https://magicmusicvisuals.com/forums/viewtopic.php?f=6&t=201
>
>
>
> on osx
>
> the equivalent is syphon and https://vdmx.vidvox.net/blog/black-syphon
>
>
> i did not try this,
>
> you need a recent gpu
>
> is there any equivalent software for linux?
>
>
>
> have a nice day
>
> Pierre-Yves
>
>
>
>
>
>
> 2018-06-07 12:05 GMT+02:00 hi via Pd-list :
>
>> Dearest Gem devs
>>
>> sorry for cross posting pd+gem
>>
>> I try to work with a Blackmagic DeckLink Duo 2 with 4 separate SDI inputs
>> on OSX. I have problems selecting the individual video streams. With
>> [pix_video] the [device ( message does not give the expected results ->
>> the cameras won’t open.
>> Does any of you have any experiences with this (or similar) hardware??
>>
>> best,
>>
>> jonas
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>> stinfo/pd-list
>>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] compiling a recent Gem for windows ? ...

[Chris Clepper]

A friend did some work on GEM for Windows 10 about a year ago.  I have
asked him for any info (I think he used MS toolchain) and possibly a
binary.  I'll post anything I get.

Chris

On Wed, Apr 18, 2018 at 12:08 PM, oliver  wrote:

> hi, dear list !
>
> does anyone in this wonderful PD-land by any chance got a self-compiled
> version of a recent Gem source for the windows platform that he/she would
> share ?
>
> the reason i'm asking is:
>
> the last official windows binary of Gem dates from 2011
> (version: 0.93.3) and has the following bug (windows only):
>
>
> https://github.com/umlaeute/Gem/issues/156
>
>
> the issue was declared closed on 14.11.17
>
> so, i assume that compiling Gem from source for windows would be a way to
> overcome this bug, am i right here ?
>
> now, sooner than i thought came the project, when i really need to be able
> to play back a big series of still images from recorded video input
> streams, so the Gem 0.93.3 windows bug strikes me right there.
>
> and this is where i'm stuck:
>
> the latest "self-compiling" guide i found for Gem is this one from 2014:
>
> https://github.com/umlaeute/Gem/wiki/How-to-build-Gem-on-Mic
> rosoft-Windows-%28MINGW%29
>
> but meanwhile a lot of things seem to have changed.
> i am using the latest MSYS. i recently successfully self-compiled a 64-bit
> version of PD, using this guide from Lucas Cordiviola:
>
> https://lists.puredata.info/pipermail/pd-list/2018-03/122089.html
>
> is there a similar howto like this existing for
> (the latest sources of) Gem for Windows ?
> what would be the 2018 equivalent of the libraries mentioned in the 2014
> guide (which MSYS doesn't seem to find)
>
> any help in this regard is highly appreciated !
>
> best
>
> oliver
>
>
> --
> 
> /// http://pendler.klingt.org //
> \\\ http://oliver.klingt.org  \\
> 
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
> stinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] a slightly nicer saturator than tanh~

[Chris Clepper]

The trick is having a very good anti-aliasing filter just like the FIR in a
high end ADC or SRC or very good mastering processors.  An IIR just won't
work well due to the phase shifting and low order stop band attenuation.  I
don't think Pd has anything built in other than fexpr~ and coefficient
selection is something of a black art to trade off between the attenuation,
taps/delay, transition band, impulse response etc.


On Fri, Oct 27, 2017 at 8:08 PM, Alexandre Torres Porres 
wrote:

>
>
> 2017-10-27 19:12 GMT-02:00 cyrille henry :
>
>> depending on the input you can also LP filter the signal before the
>> distortion.
>>
>> oversampling and filtering is the worst way to deal with aliasing, but
>> sometimes there is no other solution.
>
>
> recently I found out the results were kinda terrible and there wasn't much
> I could do about it, oversampling it to an insane amount like 512x didn't
> improve significantly at all...
>
> so I was wondering: - 1) why? Is there any other way?
>
> You say sometimes "no", but when can you? I assume you could do it better
> if you're designing oscillators and things like that, but for this kind of
> alias generated by digital audio manipulations, maybe there's nothing else
> at all? is that it?
>
> thanks
> cheers
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Pd-0.47.1 on macOS 10.11.6 hangs after quitting

[Chris Clepper]

Pd 0.46-5 and OSX 10.10.5 on a Macbook Air also hangs on quit.  Strangely
this did not happen with earlier versions of OS X 10.10 so it started
somewhere in that era.

On Thu, Dec 1, 2016 at 12:04 PM, Roman Haefeli  wrote:

> Hey all
>
> My colleague installed Pd-0.47.1 on his MacBook (10.11.6) and it hangs
> after quitting. The problem only occurs when DSP is turned on or has
> been turned on in the past. When DSP never has been turned on since
> launch of Pd, Pd quits without issues.
>
> When Pd is forcefully quit through apple menu, a 'pd' process still
> remains running while using 100% of a core.  The only way to stop that
> is with a terminal command  ('killall pd').
>
> The problem is independent from chosen audio backend, it happens with
> 'jack', 'built-in' and other back-ends.
>
> It would already be helpful to know whether that problem is specific to
> his system or if it is a general problem with Pd on 10.11.
>
> How would someone proceed to track down such an issue?
>
> Thanks,
> Roman
>
>
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [gemhead]s vs. [separator]

[Chris Clepper]

One use for [separator] is to texture the same image or video to multiple
surfaces.  Another is to control the center position of multiple geos that
are offset from that center.

On Sunday, December 6, 2015, João Pais  wrote:

> My examples are very simple, so there won't be any problems with loops and
> no rendering orders have to be calculated.
>
> Do I take from your comment that using [separator] does add more overhead
> than [gemhead]?
>
> For my simple case, it seems that using both of them has the same result.
> But I would want to know what is exactly the difference.
>
> Best,
>
> Joao
>
> The [gemhead] also controls the order of execution of chains while
> [separator] inherits that from the [gemhead].  One giant chain off a single
> [gemhead] with a bunch of [separator] will not give the same results as a
> bunch of different [gemhead] with explicit order of execution.  There is
> some overhead with [separator] that can become non-trivial if enough of
> them are used (like in a loop).
>
> One thing that helps is to always give each [gemhead] a value for render
> order.  This will avoid, or at least help understand, many problems with
> how rendering occurs.
>
> On Sat, Dec 5, 2015 at 9:15 AM, João Pais  > wrote:
>
>> Hello list,
>>
>> I don't work with GEM so regularly, so I had a question regarding
>> independent processing chains.
>> I'm showing different [shpere]s, and wanted to do individual
>> transformations on each, such as [color] and [translateXYZ]. Until now I
>> used an individual [gemhead] for each [sphere], but I just learned that it
>> can also be done using one common [gemhead] and [separator]s instead.
>>
>> I would like to learn, what are the pros and cons of each solution? Which
>> solution is more efficient and for which reasons?
>>
>>
>> Plus: [color] and [colorRBG] seem to have the same function. Besides the
>> extra inputs, is there any difference/advantage in one object instead of
>> the other?
>>
>> Best,
>>
>> jmmmp
>>
>> ___
>> 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] [gemhead]s vs. [separator]

[Chris Clepper]

The [gemhead] also controls the order of execution of chains while
[separator] inherits that from the [gemhead].  One giant chain off a single
[gemhead] with a bunch of [separator] will not give the same results as a
bunch of different [gemhead] with explicit order of execution.  There is
some overhead with [separator] that can become non-trivial if enough of
them are used (like in a loop).

One thing that helps is to always give each [gemhead] a value for render
order.  This will avoid, or at least help understand, many problems with
how rendering occurs.

On Sat, Dec 5, 2015 at 9:15 AM, João Pais  wrote:

> Hello list,
>
> I don't work with GEM so regularly, so I had a question regarding
> independent processing chains.
> I'm showing different [shpere]s, and wanted to do individual
> transformations on each, such as [color] and [translateXYZ]. Until now I
> used an individual [gemhead] for each [sphere], but I just learned that it
> can also be done using one common [gemhead] and [separator]s instead.
>
> I would like to learn, what are the pros and cons of each solution? Which
> solution is more efficient and for which reasons?
>
>
> Plus: [color] and [colorRBG] seem to have the same function. Besides the
> extra inputs, is there any difference/advantage in one object instead of
> the other?
>
> Best,
>
> jmmmp
>
> ___
> 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] compiling for Raspberry Pi 2 (was 2nd Pi 2 issue)

[Chris Clepper]

Pi 2 is a different architecture than the Pi (ARMv7 vs ARMv6 - huge changes
for floating point etc).  Try the Pd on Miller's site compiled for the UDOO
- should run fine.

On Mon, Jul 6, 2015 at 1:42 PM, Rick Snow  wrote:

> Just to clarify: This is a Raspberry Pi 2 I am using.  Maybe it needs a
> different architecture?
>
> I tried renaming as wiringPi_gpio.pd_linux then when instantiating the
> object it crashes pd.
>
> i really appreciate the suggestions.  Hopefully this will help some other
> folks as well.
>
> cheers,
> Rick
>
>
> On Mon, Jul 6, 2015 at 1:11 PM, Antoine Villeret <
> antoine.ville...@gmail.com> wrote:
>
>> hum, strange,
>>
>> I was pretty sure that pd loads l_arm on RPi,
>>
>> btw, did you try to rename the .l_arm in .pd_linux ?
>>
>> +
>> a
>>
>> --
>> do it yourself
>> http://antoine.villeret.free.fr
>>
>> 2015-07-05 23:53 GMT+02:00 Rick Snow :
>>
>>> Thanks Antoine.
>>>
>>> The pi2 does not seem to be looking for .l_arm
>>>  When I try to load the object with verbose checked I get:
>>> tried /home/pi/pd-externals/wiringPi_gpio.l_i386 and failed
>>> tried /home/pi/pd-externals/wiringPi_gpio.l_i386 and failed
>>> tried /home/pi/pd-externals/wiringPi_gpio.l_i386 and failed
>>> tried /usr/local/lib/pd-externals/wiringPi_gpio.l_i386 and failed
>>> tried /usr/lib/puredata/tcl/../extra/wiringPi_gpio.l_i386 and failed
>>> tried /usr/lib/pd/extra/wiringPi_gpio.l_i386 and failed
>>> tried /home/pi/pd-externals/wiringPi_gpio.pd_linux and failed
>>> tried /home/pi/pd-externals/wiringPi_gpio.pd_linux and failed
>>> tried /home/pi/pd-externals/wiringPi_gpio.pd_linux and failed
>>> tried /usr/local/lib/pd-externals/wiringPi_gpio.pd_linux and failed
>>> tried /usr/lib/puredata/tcl/../extra/wiringPi_gpio.pd_linux and failed
>>> tried /usr/lib/pd/extra/wiringPi_gpio.pd_linux and failed
>>> tried /home/pi/pd-externals/wiringPi_gpio/wiringPi_gpio.l_i386 and failed
>>> tried /home/pi/pd-externals/wiringPi_gpio/wiringPi_gpio.l_i386 and failed
>>> tried /home/pi/pd-externals/wiringPi_gpio/wiringPi_gpio.l_i386 and failed
>>> tried /usr/local/lib/pd-externals/wiringPi_gpio/wiringPi_gpio.l_i386 and
>>> failed
>>> tried /usr/lib/puredata/tcl/../extra/wiringPi_gpio/wiringPi_gpio.l_i386
>>> and failed
>>> tried /usr/lib/pd/extra/wiringPi_gpio/wiringPi_gpio.l_i386 and failed
>>> tried /home/pi/pd-externals/wiringPi_gpio/wiringPi_gpio.pd_linux and
>>> failed
>>> tried /home/pi/pd-externals/wiringPi_gpio/wiringPi_gpio.pd_linux and
>>> failed
>>> tried /home/pi/pd-externals/wiringPi_gpio/wiringPi_gpio.pd_linux and
>>> failed
>>> tried /usr/local/lib/pd-externals/wiringPi_gpio/wiringPi_gpio.pd_linux
>>> and failed
>>> tried /usr/lib/puredata/tcl/../extra/wiringPi_gpio/wiringPi_gpio.pd_linux
>>> and failed
>>> tried /usr/lib/pd/extra/wiringPi_gpio/wiringPi_gpio.pd_linux and failed
>>> tried /home/pi/pd-externals/wiringPi_gpio.pd and failed
>>> tried /home/pi/pd-externals/wiringPi_gpio.pd and failed
>>> tried /home/pi/pd-externals/wiringPi_gpio.pd and failed
>>> tried /usr/local/lib/pd-externals/wiringPi_gpio.pd and failed
>>> tried /usr/lib/puredata/tcl/../extra/wiringPi_gpio.pd and failed
>>> tried /usr/lib/pd/extra/wiringPi_gpio.pd and failed
>>> tried /home/pi/pd-externals/wiringPi_gpio.pat and failed
>>> tried /home/pi/pd-externals/wiringPi_gpio.pat and failed
>>> tried /home/pi/pd-externals/wiringPi_gpio.pat and failed
>>> tried /usr/local/lib/pd-externals/wiringPi_gpio.pat and failed
>>> tried /usr/lib/puredata/tcl/../extra/wiringPi_gpio.pat and failed
>>> tried /usr/lib/pd/extra/wiringPi_gpio.pat and failed
>>>  wiringPi_gpio
>>>
>>>
>>> On 7/5/15, Antoine Villeret  wrote:
>>> > 2015-07-05 23:00 GMT+02:00 Rick Snow :
>>> >
>>> >> Dear list,
>>> >>
>>> >> In addition to having trouble getting pd 46.6 to install on the
>>> Raspberry
>>> >> Pi 2 I am having trouble compiling the NYU wiringPi objects.
>>> >>
>>> >> Does anyone know which architecture the Pi 2 requires?  l_arm or
>>> >> .pd_linux?t
>>> >>
>>> > both are good candidates
>>> > but pd_linux could be of arch i686, x86_64 or arm (or even something
>>> else)
>>> >
>>> >>
>>> >> I am able to compile the objects using the provided makefile as an
>>> l_arm
>>> >> object but when I try to create a .pd_linux object with the makefile
>>> >> terminal returns:
>>> >> "* No rule to make target 'wiringPi_gpio.pd_linux'. Stop."
>>> >>
>>> >
>>> > run pd with -verbose option and look at pd's console to know what it is
>>> > trying to load when you make a [wiringPi_gpio] object
>>> > it should try to load .l_arm
>>> > +
>>> > a
>>> >
>>> >>
>>> >> same goes for the wiringPi_mcp3008.pd_linux object.
>>> >>
>>> >> Any advice greatly appreciated!
>>> >> Rick
>>> >>
>>> >> ___
>>> >> 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

Re: [PD] Granular Synthesis for Pd Eurorack Module

[Chris Clepper]

For messing around the UDOO is fine, but totally unsuitable for
incorporating in a manufactured audio product.  The Pd part is easy, the
hardware is incredibly difficult.

I actually design Eurorack modules with Tiptop Audio as my day job, and can
tell you that making a module using an advanced ARM chip is no easy task.
The Nebulae is a quick, dirty hack and it has many issues.  Design from the
ground up around an A9 or similar chip requires very advanced tools (we pay
a huge annual sum for high end layout software) and about 10 years of mixed
signal PCB design experience.  Keeping the audio clean would take multiple
revisions of a 10-12 layer board and you would need to make a Eurorack
power supply that can handle the current of the digital parts.

It would take well into 6 figures to get a fully functional production
ready prototype.

On Mon, May 18, 2015 at 11:42 AM, Pagano, Patrick  wrote:

>  Looks great Chris, only thing that is weird is that it's a mic input not
> a line in that i get with the creative card currently. Everything else
> looks fancy. Would you like my address to send it? :-)
>
>
>  I am going to take the idea to our Innovation Hub at University of
> Florida and pitch the idea for the module, if it goes they might give me
> some seed funding --then i can explore some different cards/boards. A
> friend is lending his BeagleBone Black. Seriously if you want to throw in
> with  us i'll give you p0ints later :-)
>
>
>  conspiring for a pd Module,
>
>
>   *Patrick Pagano B.S, M.F.A*
> Audio and Projection Design Faculty
> Digital Worlds Institute
> University of Florida, USA
> (352)294-2020
>   --
> *From:* Chris Clepper 
> *Sent:* Monday, May 18, 2015 11:15 AM
> *To:* Pagano, Patrick
> *Cc:* IOhannes m zmoelnig; pd-l...@mail.iem.at
> *Subject:* Re: [PD] Granular Synthesis for Pd Eurorack Module
>
>   Have you seen the UDOO board that have multi-core A9 CPUs, analog audio
> I/O and an arduino compatible microcontroller already?
>
> http://shop.udoo.org/usa/product/udoo-dual.html
>
>
>
> On Mon, May 18, 2015 at 11:00 AM, Pagano, Patrick <
> p...@digitalworlds.ufl.edu> wrote:
>
>> Thank You all for your help so far
>> I have looked at Granola~, granita, my-grainer, dsis_munger and granny a
>> port of Sakonda's famous Grain2.0 patch by bill orcutt, all of which failed
>> because of the problem with compilation that Iohannes who is always so
>> helpful mentions.
>>
>> I have chosen to go with Martin's fabulous grainsamplerfx patch and
>> modify it.
>> I have also found that ProcesoV8 and Johann's Monolog-x are wonderful
>> candidates for a true pure data module.
>>
>> I contacted Qu-bit Electronix with hopes of a complimentary board for my
>> research but they are not in a position to help me. They make a wonderful
>> product called Nebulae for Eurorack but it's just too expensive for my
>> professor salary right now. I even asked if they had scratch and dent
>> versions that they might let go of to no avail. It apparently takes pure
>> data AND Csound code but it seems a little more bent towards Csound, but
>> again this is just a quick observation.
>>
>> I have successfully connected an arduino uno to 6 potentiometers and poll
>> them with Hans' Arduino2pd patch
>> I am using a 1in/1out Creative Blaster go USB soundcard and Rpi see it
>> and loads ALSA for it
>>
>> I am experimenting now with getting the tty to be the same when i run RPI
>> without Xwindows, i have created a few lines in the inittab to hopefully
>> select that port each time but it's not working correctly. when i boot into
>> X it polls and updates the Pots but when i only use commandline they are
>> not talking to each other. The arduino is polling for sure but pd is not
>> reacting.
>>
>> Martin's patch with 6 very simple parameters sounds awesome
>>
>> I would like to have  a RT Granular Patch working and then work backwrds
>> from there because it will probably be the most processor intensive, I
>> would like to create and awesome "Curtis Filter" like Dave Smith has
>> released
>> http://www.davesmithinstruments.com/product/dsm01-curtis-filter-module/
>>
>> Is there an example in OD that replicates such a Filter --2/4 pole
>> resonant low-pass filter module?
>>
>> The Nebulae uses samples and a microSD card for loading samples which i
>> want to try to avoid, i would like to keep everything RT.
>>
>> what do you all think?
>> Please make suggestions of patches you think might be worth testing.
>> I would like to manufacture the boards a

Re: [PD] Granular Synthesis for Pd Eurorack Module

[Chris Clepper]

Have you seen the UDOO board that have multi-core A9 CPUs, analog audio I/O
and an arduino compatible microcontroller already?

http://shop.udoo.org/usa/product/udoo-dual.html



On Mon, May 18, 2015 at 11:00 AM, Pagano, Patrick  wrote:

> Thank You all for your help so far
> I have looked at Granola~, granita, my-grainer, dsis_munger and granny a
> port of Sakonda's famous Grain2.0 patch by bill orcutt, all of which failed
> because of the problem with compilation that Iohannes who is always so
> helpful mentions.
>
> I have chosen to go with Martin's fabulous grainsamplerfx patch and modify
> it.
> I have also found that ProcesoV8 and Johann's Monolog-x are wonderful
> candidates for a true pure data module.
>
> I contacted Qu-bit Electronix with hopes of a complimentary board for my
> research but they are not in a position to help me. They make a wonderful
> product called Nebulae for Eurorack but it's just too expensive for my
> professor salary right now. I even asked if they had scratch and dent
> versions that they might let go of to no avail. It apparently takes pure
> data AND Csound code but it seems a little more bent towards Csound, but
> again this is just a quick observation.
>
> I have successfully connected an arduino uno to 6 potentiometers and poll
> them with Hans' Arduino2pd patch
> I am using a 1in/1out Creative Blaster go USB soundcard and Rpi see it and
> loads ALSA for it
>
> I am experimenting now with getting the tty to be the same when i run RPI
> without Xwindows, i have created a few lines in the inittab to hopefully
> select that port each time but it's not working correctly. when i boot into
> X it polls and updates the Pots but when i only use commandline they are
> not talking to each other. The arduino is polling for sure but pd is not
> reacting.
>
> Martin's patch with 6 very simple parameters sounds awesome
>
> I would like to have  a RT Granular Patch working and then work backwrds
> from there because it will probably be the most processor intensive, I
> would like to create and awesome "Curtis Filter" like Dave Smith has
> released
> http://www.davesmithinstruments.com/product/dsm01-curtis-filter-module/
>
> Is there an example in OD that replicates such a Filter --2/4 pole
> resonant low-pass filter module?
>
> The Nebulae uses samples and a microSD card for loading samples which i
> want to try to avoid, i would like to keep everything RT.
>
> what do you all think?
> Please make suggestions of patches you think might be worth testing.
> I would like to manufacture the boards and design the prototype this
> summer since i cannot afford to direct my research to the Nebulae. This
> Fall i will have 30 graduate students coding with me so we will have ALOT
> to offer.
>
> Patrick
>
>
>
> Patrick Pagano B.S, M.F.A
> Audio and Projection Design Faculty
> Digital Worlds Institute
> University of Florida, USA
> (352)294-2020
>
> 
> From: Pd-list  on behalf of IOhannes m
> zmoelnig 
> Sent: Monday, May 18, 2015 4:52 AM
> To: pd-l...@mail.iem.at
> Subject: Re: [PD] Granular Synthesis on liv input?
>
> On 2015-05-17 19:11, Pagano, Patrick wrote:
> > It says that it's the wrong ELF class ELF CLASS64
> >
>
> you cannot use a binary for i386 or amd64 on a Raspberry Pi, which has
> an arm processor.
> you need to have a binary compiled esp. for this achitecture (read:
> compile it yourself).
>
> fgadmf
> IOhannes
>
>
> ___
> 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] new raspberries

[Chris Clepper]

In general, the ARM will do all sorts of things to keep energy usage to the
bare minimum:  Video decoding runs on dedicated DSP/GPU rather than the
main cores, parts of the cores are shutdown, RAM is put to sleep and so on.

Using -nosleep on a root process at elevated could defeat enough of the low
power safeguards as that is something an Android phone/tablet would never
do.  All of those devices have heatsinks just due to space constraints, and
Apple ran afoul of customers due to excessive heat on a dual A8 based iPad.

Without any heat treatment on top of the CPU most of the heat flows through
the PCB.  So in some cases the issue wouldn't be with the ARM but some
other part reaching its thermal limit (like a power regulator or RAM that
have to be physically close to the CPU).  The UDOO board's WiFi chip gets
hotter than the ARM heatsink for example.  Freescale recommend heat
spreaders and sinks for all of their iMX.6 parts although not all of the
low eval boards have them.

The Pi 2 doesn't have much thermal cooling on the chip and the RAM is
directly UNDER the CPU so the heat from both will largely go into the same
place PCB.  Maybe there is enough copper in the PCB to dissipate the heat,
but the thermal docs I have from Freescale say it's not possible to do for
a 5W+ quad A9.

On Mon, Feb 9, 2015 at 1:53 PM, Miller Puckette  wrote:

> Interesting.  Of course, it _should_ be thermally permitted to run all
> cores at speed - and the Pi folk are taking heat dissipation very
> seriously in their thinking.  So my leaning would be to risk $35 on a
> week-long stress test using -nosleep.  Hmm, time to order a machine...
>
> cheers
> Miller
>
> On Mon, Feb 09, 2015 at 01:13:40PM -0500, Chris Clepper wrote:
> > The ARM multicore CPUs tend to bounce processes between cores to avoid
> > thermal issues (an idle core is a cool core).  If you really want to do
> > -nosleep for a long period, think about adding a heatsink to the chip.  I
> > have had A9s lock up or shutdown pretty quickly from heat.  On the plus
> > side, I have lower latency on ARM than my new Macbook Air or any other
> > desktop I run Pd on...
> >
> > On Sat, Feb 7, 2015 at 10:52 AM, katja  wrote:
> >
> > > As an alternative to "pd -nosleep", "taskset 0x0001 pd" (as per
> > > Simon Wise's suggestion) is another way to run puredata properly on
> > > Raspberry Pi model 2B. This sets 'CPU affinity' for pd to core 1 (you
> > > could set another core in hex format). Apparently the switching
> > > between cores is detrimental to pd's dsp process. Core affinity is a
> > > side effect of pd's -nosleep option, that is probably why both
> > > approaches work. The advantage of the taskset approach is that command
> > > top or htop still show realistic CPU load for the process (with "pd
> > > -nosleep" it shows as 100% all the time).
> > >
> > > Here is a way to make pd start in taskset consistently in LXDE:
> > > 1 - create a new textfile ~/.local/share/applications/puredata.desktop
> > > 2 - copy the text from /usr/share/applications/puredata.desktop into
> > > this new file
> > > 3 - replace the string after "Exec=" with "taskset 0x0001 pd %F"
> > > 4- logout and login for the new setting to take effect
> > >
> > > Now you can start pd with 'CPU affinity' from the menu or by double
> > > clicking a patch. Not sure if this is the definitive solution, but at
> > > least it makes pd work without audio errors.
> > >
> > >
> > > Katja
> > >
> > > On Sat, Feb 7, 2015 at 10:39 AM, katja  wrote:
> > > > On Fri, Feb 6, 2015 at 11:56 PM, Miller Puckette 
> wrote:
> > > >> Also try running "pd -nosleep", which sometimes persuades kernels to
> > > >> schedule the process differently :)
> > > >
> > > > Indeed, "pd -nosleep" does the magic. Command htop shows hat the
> > > > kernel has 100% CPU time reserved on one core (fixed per session) for
> > > > pd -nosleep. Pd-gui runs on one of the other cores, alternating. The
> > > > audio is fine with no dropouts.
> > > >
> > > > It is possible to start two instances of pd -nosleep, and get a core
> > > > reserved for each. The second instance finds the alsa device busy of
> > > > course, and this makes no sense in practice. Maybe the [pd~] object
> > > > can profit from the multicore processor.
> > > >
> > > > I've checked current draw with the set

Re: [PD] new raspberries

[Chris Clepper]

The ARM multicore CPUs tend to bounce processes between cores to avoid
thermal issues (an idle core is a cool core).  If you really want to do
-nosleep for a long period, think about adding a heatsink to the chip.  I
have had A9s lock up or shutdown pretty quickly from heat.  On the plus
side, I have lower latency on ARM than my new Macbook Air or any other
desktop I run Pd on...

On Sat, Feb 7, 2015 at 10:52 AM, katja  wrote:

> As an alternative to "pd -nosleep", "taskset 0x0001 pd" (as per
> Simon Wise's suggestion) is another way to run puredata properly on
> Raspberry Pi model 2B. This sets 'CPU affinity' for pd to core 1 (you
> could set another core in hex format). Apparently the switching
> between cores is detrimental to pd's dsp process. Core affinity is a
> side effect of pd's -nosleep option, that is probably why both
> approaches work. The advantage of the taskset approach is that command
> top or htop still show realistic CPU load for the process (with "pd
> -nosleep" it shows as 100% all the time).
>
> Here is a way to make pd start in taskset consistently in LXDE:
> 1 - create a new textfile ~/.local/share/applications/puredata.desktop
> 2 - copy the text from /usr/share/applications/puredata.desktop into
> this new file
> 3 - replace the string after "Exec=" with "taskset 0x0001 pd %F"
> 4- logout and login for the new setting to take effect
>
> Now you can start pd with 'CPU affinity' from the menu or by double
> clicking a patch. Not sure if this is the definitive solution, but at
> least it makes pd work without audio errors.
>
>
> Katja
>
> On Sat, Feb 7, 2015 at 10:39 AM, katja  wrote:
> > On Fri, Feb 6, 2015 at 11:56 PM, Miller Puckette  wrote:
> >> Also try running "pd -nosleep", which sometimes persuades kernels to
> >> schedule the process differently :)
> >
> > Indeed, "pd -nosleep" does the magic. Command htop shows hat the
> > kernel has 100% CPU time reserved on one core (fixed per session) for
> > pd -nosleep. Pd-gui runs on one of the other cores, alternating. The
> > audio is fine with no dropouts.
> >
> > It is possible to start two instances of pd -nosleep, and get a core
> > reserved for each. The second instance finds the alsa device busy of
> > course, and this makes no sense in practice. Maybe the [pd~] object
> > can profit from the multicore processor.
> >
> > I've checked current draw with the setup: Raspberry Pi + USB keyboard
> > + USB mouse + USB audio interface (iMic) together consume ~400 mA with
> > only the desktop running, and ~450 mA with pd -nosleep running idle or
> > with a CPU intensive patch. This indicates there is some frequency
> > scaling going on after all. I'll look into that again when there's
> > more info about the new Pi's config defaults and options.
> >
> > Katja
>
> ___
> 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] moog

[Chris Clepper]

This is probably the source for Gunter's Moog VCF:

https://ccrma.stanford.edu/~stilti/papers/moogvcf.pdf



On Tue, Jan 13, 2015 at 8:37 PM, Alexandre Torres Porres 
wrote:

> Howdy, so David, kinda getting back from my break, thought I'd have
> anohter look at this...
>
> Seems the extended object is related to the 2004 Huovalainen paper, but
> I've failed to fully understand the code of moog.c and really match them.
>
> Anyone knows about Gunter's wherabouts these days? He could give us a
> hint. And yeah, I also saw some moog filter by Miller, which I should find
> back and check as well...
>
> Here's another cool thing I found on the web.
>
>
> http://www.acoustics.ed.ac.uk/wp-content/uploads/AMT_MSc_FinalProjects/2012__Daly__AMT_MSc_FinalProject_MoogVCF.pdf
>
> So, by looking at the Huovalainen paper, seems doable to do it with
> [fexpr~]. In the end, it's just some 4th order filter, right?
>
> Have you checked MoogFF in Supercollider?
>
> cheers
>
>
>
> 2015-01-01 13:20 GMT-02:00 Dan Wilcox :
>
> Yes please!
>>
>> 
>> Dan Wilcox
>> @danomatika
>> danomatika.com
>> robotcowboy.com
>>
>> On Dec 31, 2014, at 4:43 PM, pd-list-requ...@lists.iem.at wrote:
>>
>> I'd like to understand pd's [moog~] object one day, and implement it with
>> [fexpr~] or something. Maybe I'll do this other one as well.
>>
>>
>>
>
> ___
> 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

[Chris Clepper]

No problem, Joe.  I took everything from the canonical RBJ source:
http://www.musicdsp.org/files/Audio-EQ-Cookbook.txt

I didn't do the shelving because they are a pain in ass to do using expr.

I should mention that these calculate the bandwidth of the filter and not
Q.  I find it easier for bandpass and peaking EQ to use bw, but to have
resonance for a hi/lopass filter the values need to be low ( bw < 1).  The
abstractions should include the expr to do Q just not hooked up.

Chris


On Fri, May 23, 2014 at 7:06 AM, 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