Re: [PD] RIP Ed Kelly

[katja]

Much of Ed Kelly's website seems to be archived on archive.org, fortunately:

https://web.archive.org/web/20231201125710/http://sharktracks.co.uk/html/index.html

(took me a while to think of it, after the shocking news)


On Thu, Mar 14, 2024 at 6:37 AM Lucas Cordiviola 
wrote:

> On 13/03/2024 08:51, Julian Brooks wrote:
> > to secure what's out there & take it from there - your kind offer of
> > server access being perfect for that...
>
>
> I had created public repo
> https://git.nubegris.com.ar/org.ed.kelly.files/ed.kelly.files
>
> the org. part is to be able to give supercow powers to certain people.
>
> people willing to contribute must create an account on
> https://git.nubegris.com.ar/user/sign_up and fork the above repo. then
> submitt a PR.
>
> anyone interested but not knowing how to use git contact me
> privately(via mail or via repo) or better openly in this list.
>
> this should help to gather the files and hopefully later backups can be
> made easier.
>
>
> :)
>
> --
>
> Mensaje telepatico asistido por maquinas.
>
>
>
>
> ___
> 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] [PD-announce] [leapmotion] version 0.2.0 on deken

[katja]

On 12/28/22, Miller Puckette via Pd-list  wrote:
> I don't have a recent enough mac to compile for M1.  I'm almost ready to
> hold my nose and buy one.

It would be interesting to try cross compiler
https://github.com/tpoechtrager/osxcross. This works for externals and
might work for Pd too if we can get dependencies included.

Mac SDK requires cmake which I don't think my
> department has managed to get running on their machines yet.  UGH...
>
> M
>
> On Wed, Dec 28, 2022 at 07:49:43PM +0100, IOhannes m zmölnig wrote:
>> Am 28. Dezember 2022 16:20:08 MEZ schrieb "João Pais"
>> :
>> >ah ah actually the wink was for Miller - pd~ doesn't work on M1 yet.
>>
>> Why not?
>>
>>
>> mfg.sfg.jfd
>> IOhannes
>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!GnjYoKRjglfvBeGlFS59acO8TGTD8eP3uJFAs0vNiaBCNYPrpUqspK82DVxsgFLHJTJZThtfPLAM$
>>
>
>
>
> ___
> 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] soundtouch~ for Pd Vanilla

[katja]

On 2/2/21, Alexandre Torres Porres  wrote:

[...]
> I haven't really compared the implementations of ceammc, but what usually
> happens is that externals from ceammc have some particularities that are
> special to that fork of Pd, like special messages using "@", and they're
> usually integrated into that system. Having a single, light, updated and
> independent version of soundtouch~ for all systems seems like a good idea.
[...]

In the meantime I did some attempts to build pd-ceammc but failed so
still can't compare, but I get your point. The method(s) to avoid
nameclash could be documented in the readme text.



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

[PD] soundtouch~ for Pd Vanilla

[katja]

> Em qua., 27 de jan. de 2021 às 07:12, katja 
> escreveu:
>
>> Doesn't build, load, or what? If you create a branch with your
>> pd-lib-builder attempt, someone might help figure out why it "doesn't
>> work" (I'm not promising it'll be me).
>>
>
>  I haven't really even tried properly. I just tried in the most lazy
> attempt to include pd-lib-builder and it didn't work (no surprise). Then I
> tried the makefle as it is and it was a success, so I guess other can build
> with it just fine. Perhaps other people with better knowledge on how
> makefiles work can help and make an actual (and probably successful)
> attempt. I'll merge and we can make a "1.0" release with that.

SoundTouch (from Olli Parviainen
https://gitlab.com/soundtouch/soundtouch) uses an autotools build
system with configure script. For a makefile approach these
configurations have to be figured out (per platform).

However, I'm not sure whether brushing up this old port is worth the
effort, also considering the nameclash potential. The CEAMMC port
seems to expose more options from the library (anti-aliasing):

https://github.com/uliss/pure-data/blob/ceammc/ceammc/extra/SoundTouch/pd/soundtouch_tilde.cpp

Unfortunately there's no Linux build of CEAMMC in deken so I couldn't
quickly compare implementations. Porres can you explain the reason for
updating an old port while there is a maintained implementation
available?



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

Re: [PD] soundtouch~ for Pd Vanilla

[katja]

On 1/27/21, Alexandre Torres Porres  wrote:
> Em ter., 26 de jan. de 2021 às 22:47, Alexandre Torres Porres <
> por...@gmail.com> escreveu:
>
>> It was developed with SoundTouch version 1.6
>>
>
> The latest stable release is 2.1.1, by the way... I guess we should update
> to the new version, right?
>
>>
>

The port based on 1.6 is very old, maybe 10 years or so.



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

Re: [PD] soundtouch~ for Pd Vanilla

[katja]

On 1/27/21, Alexandre Torres Porres  wrote:
> Hi folks, I'm on a vibe of uploading missing libraries and objects for Pd
> Vanilla on deken. On the list I have FFTease, Lyonpotpourri, CICM-Tools and
> more stuff that I'm looking into, just so you know...
>
> Now, I see there's an old soundtouch~ external here:
> http://www.katjaas.nl/pitchshift/soundtouch~.html - it's "version 0.9" by
> Katja Vetter. It was developed with SoundTouch version 1.6 and Pure Data
> version 0.42. I tested on Pd 0.51-4 32 bits on mac and it works fine. There
> are binaries for download on the link above, but not for 64 bits. I wonder
> if anyone wants to help me build these with pd-lib-builder and all.
>
> Now, the ceammc librarym (and Pd-ceammc distribution) has a soundtouch~
> external too. It's the same name, but not the same external, this one is
> marked as "version 0.1". So we do already have "a" soundtouch~ for vanilla,
> but I wanted to also get katja's external up there.
>
> So I just uploaded the download from that page here
> https://github.com/porres/pd-soundtouch - It's just the download as it is
> and we need to change to hopefully use pd-lib-builder, which would make
> things easier. I did try that and it didn't work.

Doesn't build, load, or what? If you create a branch with your
pd-lib-builder attempt, someone might help figure out why it "doesn't
work" (I'm not promising it'll be me).

>
> So, anyone onboard with this?
>
> cheers
>



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

Re: [PD] Yin algorithm

[katja]

Jaime do you refer to [helmholtz~]
(www.katjaas.nl/helmholtz/helmholtz.html)? This uses a time domain
method, but based on normalized autocorrelation whereas yin uses
differences if I remember well.

On 7/12/20, Jaime Oliver  wrote:
> Katja Vetter has a similar one.
> Best,
> J
>
> On Sun, Jul 12, 2020, 11:18 AM Vinicius Cesar
> 
> wrote:
>
>> Hi everybody,
>>
>> Does anyone know if there's any implementation of yin algorithm for
>> fundamental frequency estimation in PD?
>>
>>
>> Akk the best,
>>
>> Vinicius
>> ___
>> 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] sending lists via [comport]

[katja]

Have you tried the abstractions in https://github.com/alexdrymonitis/Arduino_Pd?

On 1/28/20, Dr. Maik Hester  wrote:
> Dear list,
>
> does anyone know how to send the different values of each line from the
> sample below to [comport] as a list, strip this list in [pd] and route
> the values to their different destinations?
>
> The data comes via Arduino from a pixy cam.
>
> Here is a sample from Arduino's serial monitor:
>
> Detected 6
>    block 0: sig: 2 x: 273 y: 36 width: 42 height: 5 index: 41 age: 18
>    block 1: sig: 1 x: 272 y: 187 width: 36 height: 4 index: 37 age: 18
>    block 2: sig: 1 x: 266 y: 151 width: 28 height: 4 index: 226 age: 71
>    block 3: sig: 1 x: 274 y: 109 width: 20 height: 4 index: 155 age: 124
>    block 4: sig: 2 x: 280 y: 48 width: 32 height: 2 index: 223 age: 72
>    block 5: sig: 1 x: 240 y: 136 width: 24 height: 2 index: 52 age: 5
>
> At the moment [comport] receives all the numbers one after another (e.g.
> 2  273  36  42  5  41  18 ...), so that it is impossible for me to tell
> [pd] which number should go where.
>
> I kept checking the internet for a solution for several days which did
> not bring me any further, so I hope that someone in the [pd] community
> could give me a clou.
>
> Thanks
> Maik
>
>
>
>
> --
> __
> Dr. Maik Hester
> Musiker, Musikwissenschaftler, Akkordeon-Restaurator
> Himmelohstraße 23
> D-58454 Witten
>
>
>
>
> ___
> 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] lib nilwind: continuation of cyclone 0.2x as fallback provision

[katja]

Some weeks ago Fred Jan Kraan has reissued cyclone 0.2.1 as 'nilwind'
on github and deken. It happened upon my request, to enable
coinstallation of 0.2x with newer versions. Alexandre does a great job
in preserving backward compatibility (much appreciated!). But the
library has also been subject to major refactoring which happened
without publicly visible discussion or documentation of the approach.
Regressions resulting from this appear hard to solve.

For this reason it is useful to have old cyclone still at hand as a
fallback. With nilwind around I could finally release an update of a
cyclone-dependent project without worrying about stability. Fred Jan
declared his intention to maintain nilwind for this sort of purpose.
Serious bugs and issues arising from external conditions may be fixed,
but behavior of objects won't be changed otherwise. The lib name says
it all.

Renaming a library doesn't automatically resolve name clash of
individual classes. It is therefore recommended to instantiate objects
with the library prefix, as [nilwind/]. This is also how
cyclone and nilwind help patches instantiate objects.



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

[PD] [PD-announce] Slice//Jockey for vanilla Pd

[katja]

Several people asked for an update of project Slice//Jockey. It dates
from Pd-Extended times. SliceJockey3 finally works with vanilla Pd.
Find it here:

www.katjaas.nl/slicejockey/slicejockey.html

It needs a few external libraries which are available from deken for
all current platforms. The project was verified to work on Linux
(Intel and ARM), MacOS and Windows (tested through Wine).



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

Re: [PD] pitch tracking...

[katja]

Joel de Guzman is very generous to share this intriguing Bitstream
Autocorrelation concept and also an implementation in C++. That
implementation is for platforms like microcontroller and DSP chip
where IO samples are integers. Not sure if the bitstream approach will
compare so favorably against FFT based autocorrelation within a float
oriented framework like Pd on general purpose architectures.

On 12/13/19, Simon Iten  wrote:
> hi all and katja :-)
>
> have you seen this:
>
> https://www.cycfi.com/2018/04/fast-and-efficient-pitch-detection-bliss/
> <https://www.cycfi.com/2018/04/fast-and-efficient-pitch-detection-bliss/>
>
> seems like a very good canditate for a fast and accurate pitch detector in a
> pd external, no?
>
>
>



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

[PD] Forum pdpatchrepo.info subscription issue

[katja]

On 11/1/19, Adams AJAVON  wrote:
> Hi...
>
> Does anyone know how to contact the admin of the pdpatchrepo.info forum ?
> Their registration process doesnt work After registring it is supposed
> to send a confirmation email... but it's never received... I tried 3
> times It never worked... I am registered but I can not post anything
> over there

In 2014 I sent an email to fo...@pdpatchrepo.info and got response
from a human, not sure if that still works.

Katja



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

[PD] autotune external for OSX anyone?

[katja]

On 10/31/19, enrike  wrote:

> Compiling the code is not an option in this case, I don't have a mac I
> could setup to compile and I would not like to mess the student's machine.

You could cross-compile for OSX using the osxcross project:

https://github.com/tpoechtrager/osxcross

I just started using it on Debian-based Linux to compile Pd externals,
works great.

> ___
> 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] soundtouch~ status quo (was: soundtouch~, slicerec/sliceplay for 64 bit windows?)

[katja]

On 10/30/19, Christof Ressi  wrote:
> The problem is actually in the code:
>
> (SAMPLETYPE *)(((ulong)tempUnaligned + 15) & (ulong)-16);
>
> This line probably tries to align memory on the stack to 16 bytes boundaries
> for SSE code. The problem is that "ulong" is a typedef for "unsigned long".
> The code assumes that "long" always has the size of a pointer (4 bytes on 32
> bit and 8 bytes on 64 bit), but on Windows it is always 4 bytes, so on 64
> bit you get a size mismatch.

Christof thanks for your analysis and explanation.

To be clear about the current state of soundtouch~: it is a (partial)
port for Pd of Olli Parviainen's SoundTouch library. Olli's project is
probably up to date with the latest platforms but the port was derived
(by me) from an earlier version back in 2011. Ideally soundtouch~ for
pd should be realigned with latest SoundTouch from Olli, and also get
a new build system. Maybe not horribly much work but frankly it can't
be high my todo list. If someone is interested to adopt this project,
take a look at Olli's SoundTouch project and my page describing the
port for pd:

www.surina.net/soundtouch/
www.katjaas.nl/pitchshift/soundtouch~.html

(And to avoid confusion about the other classes mentioned in subject
title: slicerec~/sliceplay will be soon updated by me in the context
of Slice//Jockey).

Katja


>
> A quick and dirty fix: find the relevant "#define" or "typedef" for "ulong"
> and set it to "unsigned long long" for 64 bit Windows:
>
> #ifdef _WIN64
> #define ulong unsigned long long
> #else
> #define ulong unsigned long
> #endif
>
> Please make a bug report to the upstream author.
>
> Christof
> Gesendet: Mittwoch, 30. Oktober 2019 um 00:46 Uhr
> Von: "pat pagano" 
> An: pd-l...@iem.at
> Betreff: Re: [PD] soundtouch~, slicerec/sliceplay for 64 bit windows?
>
> I know that i am flailing with windows makefiles but i was hopeful that from
> trying to compile such an essential external for a few patches i've written
> with it I would learn compiling externals more clearly for pd and of course
> windows
>
> here's what i get:
>
> g++ -m64 -msse -DNT -DPD_LONGINTTYPE=__int64 -DMSW -Wall -Wextra -Wshadow
> -Wint-to-pointer-cast -Winline -Wstrict-aliasing -O3 -ffast-math
> -funroll-loops -fomit-frame-pointer -march=core2 -msse -msse2 -msse3
> -mfpmath=sse -I ./include -c *.cpp
> FIFOSampleBuffer.cpp: In member function 'void
> soundtouch::FIFOSampleBuffer::ensureCapacity(uint)':
> FIFOSampleBuffer.cpp:181:39: error: cast from 'soundtouch::SAMPLETYPE*' {aka
> 'float*'} to 'ulong' {aka 'long unsigned int'} loses precision
> [-fpermissive]
>  temp = (SAMPLETYPE *)(((ulong)tempUnaligned + 15) & (ulong)-16);
>^
> FIFOSampleBuffer.cpp:181:71: warning: cast to pointer from integer of
> different size [-Wint-to-pointer-cast]
>  temp = (SAMPLETYPE *)(((ulong)tempUnaligned + 15) & (ulong)-16);
>^
> FIRFilter.cpp: In static member function 'static void*
> soundtouch::FIRFilter::operator new(size_t)':
> FIRFilter.cpp:222:39: warning: unused parameter 's' [-Wunused-parameter]
>  void * FIRFilter::operator new(size_t s)
> ~~~^
> RateTransposer.cpp: In static member function 'static void*
> soundtouch::RateTransposer::operator new(size_t)':
> RateTransposer.cpp:109:44: warning: unused parameter 's'
> [-Wunused-parameter]
>  void * RateTransposer::operator new(size_t s)
>  ~~~^
> soundtouch~.cpp: In function 't_int* soundtouch_perform(t_int*)':
> soundtouch~.cpp:91:39: warning: cast to pointer from integer of different
> size [-Wint-to-pointer-cast]
>   t_soundtouch *x = (t_soundtouch *)w[1];// pointer to object
> (struct instance)
>^
> soundtouch~.cpp:92:43: warning: cast to pointer from integer of different
> size [-Wint-to-pointer-cast]
>   t_sample *signalvectorIn = (t_sample*)w[2];   // pointer to input
> signal vector
>^
> soundtouch~.cpp:93:44: warning: cast to pointer from integer of different
> size [-Wint-to-pointer-cast]
>   t_sample *signalvectorOut = (t_sample*)w[3];   // pointer to output
> signal vector
> ^
> soundtouch~.cpp: In function 't_int* soundtouch_perform2(t_int*)':
> soundtouch~.cpp:115:39: warning: cast to pointer from integer of different
> size [-Wint-to-pointer-cast]
>   t_soundtouch *x = (t_soundtouch *)w[1];// pointer to object
> (struct instance)
>   

[PD] soundtouch~, slicerec/sliceplay for 64 bit windows?

[katja]

On 10/29/19, pat pagano  wrote:
> Hello
> I am hoping someone might have a version of soundtouch and or
> sliceplay~/slicerec for windows 64bit?
>
> I tired compiling them myself but i keep getting errors so i thought i
> would ask her hopefully to find someone else who might be interested in
> these externals too

These are older projects with build systems never tested on Windows 64.

Classes sliceplay~ and slicerec~ are distributed in the context of
project Slice//Jockey. As it happens I'm currently working on an
update of this project and expect to release it in one or two weeks,
including new build system and binaries for 'all' platforms.

About soundtouch~ on the other hand, not sure if it will be easy to
make it build for 'all' platforms.

Katja



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

[PD] installing pd via apt-get

[katja]

On 9/21/19, Alexandre Torres Porres  wrote:

> it might be clear that I'm completely clueless on linux and I'm just using
> it because I want to know how to work with Pd in Linux and test my
> externals in linux. So, where is this documentation?

In such case it is probably easier to use Synaptic, a GUI interface to
the package manager.

$ sudo apt install synaptic

Synaptic lets you inspect package properties, dependencies etc.
through menu items.


Katja



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

Re: [PD] [PD-dev] Why don't we implement zooming in Tcl?

[katja]

Whether considering major or minor surgery; it helps that Pd is a GUI
toolkit in its own right, albeit domain specific. Pd could rely more
on its own widgets and internal message system to display dialog
windows, thus reducing the nessecary amount of GUI-specific code. It
is hard to explain in a few words but this experiment illustrates the
approach, a generic mouse widget using an abstraction as its
properties dialog:

https://github.com/katjav/pd-mouse-trial

A bonus of reusing Pd's powerful widgets: numbox (and here also the 2
dimensional mouse widget itself) can resize an object. No handles
needed, imagine the lines of code being avoided this way.

Katja

On 8/27/19, Christof Ressi  wrote:
> Ideally we could manage to have the generic GUI interface as a compile time
> option, so that the current Pd vanilla code could remain unchanged for
> people who want to continue using the Tcl/Tk GUI. This would also mean that
> the GUI interface could be as radical as possible, because it wouldn't
> affect existing code/patches.
>
> In my dream world, Pd wouldn't know anything about its GUI editor. It would
> just say: create the GUI part of "thing" for me and get notifications if
> "thing" was moved, destroyed or clicked on. So no raw mouse events and
> hitbox testing on the core (modern GUI frameworks like Qt already do this
> automatically, and in a very optimized way).
>
> Christof
>
>> Gesendet: Dienstag, 27. August 2019 um 04:52 Uhr
>> Von: "Christof Ressi" 
>> An: "Miller Puckette" , Pd-List 
>> Betreff: Re: [PD] [PD-dev] Why don't we implement zooming in Tcl?
>>
>> Hi,
>>
>> > Write or find a Tcl parser and bind all the tcl comands coming from Pd
>> > to
>> > new functions written for whatever toolkit you like.
>>
>> This is what I would like to avoid my all means :-) The Tcl commands are,
>> well, just too Tcl specific.
>>
>> > Make an abstraction layer between Pd and the TCL calls, and swap in
>> > compatible
>> > calls to another toolkit.  This has been proposed a few times but seems
>> > like
>> > major surgery.
>>
>> I think this is the way to go! It would certainly require major surgery
>> but I think it would pay off tremendously in the future, because people
>> could easily do alternative GUIs without forking the core. But first
>> someone has to come up with a proof of concept.
>>
>> Christof
>>
>>
>> > Gesendet: Dienstag, 27. August 2019 um 03:43 Uhr
>> > Von: "Miller Puckette" 
>> > An: "Christof Ressi" 
>> > Cc: pd-dev 
>> > Betreff: Re: [PD-dev] Why don't we implement zooming in Tcl?
>> >
>> > Well, possiblities:
>> >
>> > Rip the GUI out and replace it (this is done in Purr Data)
>> >
>> > Write or find a Tcl parser and bind all the tcl comands coming from Pd
>> > to
>> > new functions written for whatever toolkit you like.  This was done once
>> > by a very smart person and shown (I think) at the first Pure Data
>> > Convention
>> > (Graz!)  Perhas Iohannes will remember who this was or know how to find
>> > it.
>> > Maybe it's even in the Pd convention book...
>> >
>> > Make an abstraction layer between Pd and the TCL calls, and swap in
>> > compatible
>> > calls to another toolkit.  This has been proposed a few times but seems
>> > like
>> > major surgery.
>> >
>> > (previous suggestoin, lite version) - Hang onto Tcl/Tkfor dialogs and
>> > the
>> > like, but redo the "pd window" calls using some other toolkit (less
>> > major
>> > surgery, but then you're using two toolkits, ugh.)
>> >
>> > Do somtheing not int he above list (and that I haven't though of :)
>> >
>> > M
>> >
>> >
>> > On Tue, Aug 27, 2019 at 02:38:17AM +0200, Christof Ressi wrote:
>> > > > Maybe I'm missing something obvious?
>> > >
>> > > Of course I did... We send raw Tcl commands from the core with the
>> > > actual canvas coordinates and this complicates things because of how
>> > > Tk's "scale" method works...
>> > >
>> > > Maybe it's time to eventually refactor the GUI messaging and use
>> > > abstract commands instead of actual Tcl code, with logical coordinates
>> > > instead of actual coordinates... This would mean that zooming could be
>> > > implemented easily on the GUI side.
>> > >
>> > > But what's more important: people can 

Re: [PD] [PD-announce] timbreID 0.8.1

[katja]

On 8/2/19, Christof Ressi  wrote:
> ah, for this to work you'd have to make sure that "timbreID_setup" is not
> exported... pd-lib-builder exports all non-static functions by default...

... because gcc exports all non-static functions by default. No need
to hack Makefile.pdlibbuilder, a library makefile can overrule the
default with:

ldflags := -fvisibility=hidden



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

Re: [PD] hints on how to compile for mac PPC on an intel

[katja]

On 6/12/19, Alexandre Torres Porres  wrote:
> Hi, I thought I had taken care of every platform when compiling my
> externals, but there's still PPC to go :)
>
> Any hints on how to compile for mac PPC on an intel mac?


What archs are supported depends on XCode version in the first place,
and the XCode version in turn is to an extent related to OSX version.
Somewhere during the lifetime of OSX 10.6, support for PPC was
discontinued if I remember correctly. Current pdlibbuilder by default
tries to build the fattest possible pd binaries (PPC i386 x86_64) on
OSX i386. Best chances to get all the archs are with OSX 10.5 and the
XCode versions supplied with that system.

Katja



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

Re: [PD] Full stop '.' in class namespace

[katja]

On 5/11/19, Jonathan Wilkes via Pd-list  wrote:
[...]
> 1. A cautious user will always leverage Pd's general collision avoidance by
> prefixing your library's directory
> name in the object box.

Does prefixing with libdir name avoid collision? Is it the case that
Pd can have classes like [cyclone/svf~] and [bsaylor/svf~] loaded
simultaneously?

Katja

> -Jonathan
>
>> Cheers,
>> J.
>



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

Re: [PD] get keyboard events without repeats (in 2019)

[katja]

One workaround (that I'm using in practice since long) is to hold back
the keyup message for slightly longer than the repeat time, and only
let it through when keydown didn't come again in the meantime. The
method introduces latency on keyup but not on keydown. See attached
patch, it is slightly too complicated for ASCII illustration.

Katja


On 3/18/19, Peter P.  wrote:
> Hi list,
>
> chiming in to the discussion of possible improvements regarding mice and
> now also keyboards, I am wondering if there could be a way within Pd to get
> keyboard events without having the operating systems (all three of them)
> repeat key down/up events in rapid succession.
>
> I know that I can tell the operating systems to disable it but would
> absolutely prefer Pd's keyboard objects to get these without repeats.
>
> Happy to hear any feedback on that!
> P
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
#N canvas 360 291 455 410 10;
#X obj 34 7 key;
#X obj 88 7 keyup;
#X obj 99 260 print;
#X obj 34 103 moses 1;
#X msg 73 128 clear;
#X obj 99 216 change;
#X obj 108 239 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
-1 -1;
#X obj 34 191 pipe 45;
#X obj 88 39 sel 32;
#X msg 88 68 0;
#X obj 34 39 sel 32;
#X msg 34 67 1;
#X text 137 39 test with space key;
#X floatatom 73 167 5 0 0 0 - - -;
#X text 26 294 Anti-repeat trick: the 0 message is held back for 45
ms and when a 1 message is received in the meantime \, the 0 message
is cleared from the pipe object. Note that this causes 45 ms added
latency in the keyup message \, but not in the keydown message. Delay
time may be set shorter \, depending on system settings.;
#X text 28 374 Katja Vetter March 2019;
#X connect 0 0 10 0;
#X connect 1 0 8 0;
#X connect 3 0 7 0;
#X connect 3 1 4 0;
#X connect 3 1 5 0;
#X connect 4 0 7 0;
#X connect 5 0 2 0;
#X connect 5 0 6 0;
#X connect 7 0 5 0;
#X connect 8 0 9 0;
#X connect 9 0 3 0;
#X connect 10 0 11 0;
#X connect 11 0 3 0;
#X connect 13 0 7 1;
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Status of PD double precision

[katja]

On 12/17/18, Thomas Grill  wrote:

> No time to check deeper now, but to my surprise
> CFLAGS "-D PD_FLOATSIZE=64" ./configure && make
> does indeed compile from the vanilla git repo (but doesn't link with
> portmidi and portaudio for other reasons).
> The definitions in m_pd.h suggest that t_float becomes double...


Successful compilation with 64 bit floats is a first step but doesn't
tell so much in itself. By the way it is better to override CPPFLAGS,
not CFLAGS (which holds important flags):

$ make CPPFLAGS="-D PD_FLOATSIZE=64"

This builds Pd with 64 bit floats indeed. The question is, to what
extent does it work? This page provides a .zip with some test patches
that illustrate hotspots of precision problems:

https://katjaas.nl/doubleprecision/doubleprecision.html

The patches were made in 2011 to test pd-double but they are still
useful. For example patch "03precision-tests/limits.pd" gives proof of
double precision when showing very small and large numbers that single
precision can't do.

Though Pd 0.49 compiled as above shows those small and large numbers,
it can't show all significant decimals in the GUI. This of course
limits the usefulness of double precision and also complicates the
interpretation of other tests.

Katja



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

Re: [PD] multiple instances of a patch forbidden in 0.49, why?

[katja]

Miller do you mean to extend the single-open mechanism from the doc
files to the 'file>open' menu? Like when you try to open a C file in
Geany while it is already open, Geany will pop the existing one rather
than open a second instance. For a code editor that makes sense. And
Pd is a code editor after all. But it is a code interpreter at the
same time, which is exactly why Pd is so great for education and
prototyping. And for an interpreter it doesn't always make sense to
prohibit multiple instances of a program, it just depends on the
nature of the work. Let me give an example: Martin Brinkmann's
Chaosmonster (http://www.martin-brinkmann.de/pd-patches.html) is an
wonderful sound generator on a small patch. Depending on parameter
settings it can produce very different sounds and it's fun to load a
few of them. I know people who use the patch in live performance.
Imagine their surprise when Pd refuses to load more than one.

The question when multiple instances are useful or potentionally
harmful is complex. Even when loading from 'menu>open' is restricted
to a single instance (which I hope is not going to be default
behavior), it is still possible to edit multiple instances of an
abstraction, causing the confusion and frustration that I remember
indeed from my first year with Pd. Probably there's even more details
and possible situations than we've discussed so far. On the other
hand, it is true that a single-instance-from-menu mechanism would not
raise patch-compatibility issues. So you could evaluate the effect in
classroom and pd community, then decide if it is worth keeping it.

By the way my own current use case for multiple instances is unrelated
to the menu. I'm working on a mouse widget that communicates with a pd
patch as properties dialog. In other words it uses Pd's own message
system and widgets to set its properties. Some advantages of this
arrangement were unexpected and I was just about to praise Pd for its
self-supportiveness and flexibility when stumbling into the new
no-duplicates behavior. At least for this project the issue is solved.
More about it later.

And thanks for listening to pd users even under the pressure of the
upcoming semester.


On 9/23/18, Miller Puckette  wrote:
> actually, it's probably not a serious problem that one can multiply open
> help
> files (if one really wants to), so probably it's not worth fixing this.
>
> On the other hand, a naive user on a Mac would expect that clicking on a
> file in the "finder", if Pd already has the file open, would show the user
> the open file instead of opening another copy.
>
> Supposing the "open" menu called "pd open" with the third nonzero argument,
> but if "pd open" acted as it does now so that one could programmatically
> open multiple copies of a patch, would this permit you to do what you're
> planning?  (I think that this would be patch-level back compatible).
>
> cheers
> Miller
>
> On Sun, Sep 23, 2018 at 11:52:54AM +0200, katja wrote:
>> Thanks Miller for this quick yet powerful fix.
>>
>> It currently operates on patches as opened from the window menu. Help
>> patches can still be opened more than once from the contextual menu. I
>> verified that this can be fixed by calling glob_open() instead of
>> glob_evalfile() from open_via_helppath() in s_path.c:
>>
>> glob_open(0, gensym((char*)basename), gensym(dirbuf), (t_floatarg)1);
>>
>> However to make it work, the prototype of glob_open() must be declared
>> when compiling s_path.c, otherwise the float argument is not passed
>> correctly for some reason (while the file and dir name are, isn't that
>> odd?)
>>
>> Katja
>>
>> On 9/23/18, Miller Puckette  wrote:
>> > Well, I ended up simply reverting to the old behavior but leaving a hook
>> > in
>> > so that users can specifically ask only to open a patch once.
>> >
>> > cheers
>> > M
>> >
>> > On Sun, Sep 23, 2018 at 12:10:01AM +0200, Antoine Rousseau wrote:
>> >> Yes I realized that. So it should be something more specific.
>> >> Why not a wider scope object, like [pdconfig], that would take "once"
>> >> as
>> >> an
>> >> argument?
>> >>
>> >> Antoine Rousseau
>> >>   http://www.metalu.net <http://metalu.net> __
>> >> http://www.metaluachahuter.com/
>> >> <http://www.metaluachahuter.com/compagnies/al1-ant1/>
>> >>
>> >>
>> >>
>> >> Le sam. 22 sept. 2018 ?? 23:55, Roman Haefeli  a
>> >> ??crit :
>> >>
>> >> > On Sat, 2018-09-22 at 23:29 +0200, Antoine Rousseau wrote:
>> >> > > Of course [once] wo

Re: [PD] multiple instances of a patch forbidden in 0.49, why?

[katja]

Thanks Miller for this quick yet powerful fix.

It currently operates on patches as opened from the window menu. Help
patches can still be opened more than once from the contextual menu. I
verified that this can be fixed by calling glob_open() instead of
glob_evalfile() from open_via_helppath() in s_path.c:

glob_open(0, gensym((char*)basename), gensym(dirbuf), (t_floatarg)1);

However to make it work, the prototype of glob_open() must be declared
when compiling s_path.c, otherwise the float argument is not passed
correctly for some reason (while the file and dir name are, isn't that
odd?)

Katja

On 9/23/18, Miller Puckette  wrote:
> Well, I ended up simply reverting to the old behavior but leaving a hook in
> so that users can specifically ask only to open a patch once.
>
> cheers
> M
>
> On Sun, Sep 23, 2018 at 12:10:01AM +0200, Antoine Rousseau wrote:
>> Yes I realized that. So it should be something more specific.
>> Why not a wider scope object, like [pdconfig], that would take "once" as
>> an
>> argument?
>>
>> Antoine Rousseau
>>   http://www.metalu.net <http://metalu.net> __
>> http://www.metaluachahuter.com/
>> <http://www.metaluachahuter.com/compagnies/al1-ant1/>
>>
>>
>>
>> Le sam. 22 sept. 2018 ?? 23:55, Roman Haefeli  a
>> ??crit :
>>
>> > On Sat, 2018-09-22 at 23:29 +0200, Antoine Rousseau wrote:
>> > > Of course [once] would be much better than [lock]
>> >
>> > [once] is taken by iemlib. Not that I think every library in existence
>> > should be considered regarding name conflicts when introducing new
>> > objects to Pd, but I feel that [once] is in wide use and adding a
>> > [once] with totally different behavior would be a bold move.
>> >
>> > 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
>
>
>
>
> ___
> 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] multiple instances of a patch forbidden in 0.49, why?

[katja]

Sorry for reporting this so late in the test phase. One thing that
surprises me is, why would it be considered an accident to open more
than one instance of the same patch? This depends on the purpose of a
patch or project. For the audio test it makes no sense indeed to open
more than one. On the other hand, uses cases for multiple instances
are innumerable, for live performance, analysis, and who knows what
else. A patch is a tool and no one can tell how people use it. I would
rather say that unintentionally loading the same patch twice is a
mistake, but not one that pd must take care of by prohibiting it. A
popup warning or the like would be annoying enough in my view. Not
sure what would be a good solution. Frankly I'm just perplexed that
this protective behavior came up in pd.

Katja


On 9/22/18, Miller Puckette  wrote:
> Oh dear, I was worried this might cause problems.
>
> The rationale is that, especially for beginning users but often for
> experienced ones, it is rarely desirable to have two copies of, for
> instance, the test tone patch running at once.  (An example from my own
> usage is that I have a "play" shell command that opens a patch to play
> a soundfile but I don't want to spawn a new one every time I want to play
> a new file.)
>
> Anyhow, to make the old behavior possible (which I think is only useful for
> experts) I could imagine a couple of ways:
>
> 1) ugly workaround, make symlinks to the same patch so it can be opened
> (and then managed) via different filenames or directory names)
>
> 2) I could add a message to pd or perhaps a startup flag, or both, to
> switch the behavior on and off.
>
> 3) (I doubt this is a good idea) I could make it "0.48 compatible" to open
> duplicates.
>
> Which do you think is the better option?  Any of these would be easy for me
> to accomodate.
>
> cheers
> Miller
>
> On Sat, Sep 22, 2018 at 03:17:20PM +0200, katja wrote:
>> Much to my alarm, Pd 0.49test3 prevents loading multiple instances of
>> a patch, and release notes tell us that this is on purpose. Moreover,
>> when trying to load a patch twice, pd becomes unresponsive in some
>> cases.
>>
>> The new behavior is a show stopper for projects that rely on, or
>> benefit from, loading multiple instances from a patch. As it happens
>> I'm currently working on such a project. So my questions are: what is
>> the rationale behind this 'feature', and is it really going to stay?
>>
>> Katja
>>
>>
>>
>> ___
>> 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] multiple instances of a patch forbidden in 0.49, why?

[katja]

Much to my alarm, Pd 0.49test3 prevents loading multiple instances of
a patch, and release notes tell us that this is on purpose. Moreover,
when trying to load a patch twice, pd becomes unresponsive in some
cases.

The new behavior is a show stopper for projects that rely on, or
benefit from, loading multiple instances from a patch. As it happens
I'm currently working on such a project. So my questions are: what is
the rationale behind this 'feature', and is it really going to stay?

Katja



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

Re: [PD] Slider/Knob

[katja]

On 9/8/18, Antoine Rousseau  wrote:
> too bad, newclick(...) is never called when in edit mode...
> so: no hovering detection when in edit mode, no way to (easily) detect edit
> mode on/off switching... back to the starting point.
> maybe i will... do nothing more ;-)

You could use the select function in the widgetbehavior to draw /
erase an outline with IOlets. A similar thing happens in
iemgui/iem_event (although it only does an outline, no IOlets). So the
outline + IOlets would appear when the object is selected. In
my_canvas the select method is used to switch the outline color but in
iem_event the rectangle is created when the object selected, and
deleted when the object deselected.  Another option is to define
IOlets which consist of outline only and switch outline width between
0 and 1 when (de)selecting.

Katja

>
> Antoine Rousseau
>   http://www.metalu.net <http://metalu.net> __
> http://www.metaluachahuter.com/
> <http://www.metaluachahuter.com/compagnies/al1-ant1/>
>
>
>
> Le ven. 7 sept. 2018 à 20:33, Christof Ressi  a
> écrit :
>
>> cool!
>>
>> > why not even showing outline and iolets as soon as the patch is
>> > switched
>> to edit mode?
>>
>> the only type of object inside the canvas which gets notified on editmode
>> changes is T_TEXT (to toggle the vertical line on the right), so AFAICT
>> it's impossible to achieve without nasty tricks (see
>> iemguts/receivecanvas
>> :-))
>>
>>
>> Gesendet: Freitag, 07. September 2018 um 19:39 Uhr
>> Von: "Antoine Rousseau" 
>> An: "anto...@metalu.net" 
>> Cc: "Christof Ressi" , Pd-list <
>> Pd-list@lists.iem.at>
>> Betreff: Re: Re: Re: [PD] Slider/Knob
>>
>> OK I just tried and mknob_newclick allows receiving hovering as you said
>> before.
>>
>>
>> Antoine Rousseau
>>   http://www.metalu.net[http://metalu.net] __
>> http://www.metaluachahuter.com/[http://www.metaluachahuter.com/compagnies/al1-ant1/]
>>
>>
>> Le ven. 7 sept. 2018 à 19:32, Antoine Rousseau
>> > anto...@metalu.net]> a écrit :
>>
>> I see; why not even showing outline and iolets as soon as the patch is
>> switched to edit mode?
>> But I must admit I don't know how to detect these events (object is
>> hovered /or/ patch switches to /from edit mode). I'll try to find
>> existing
>> similar code, but maybe you have some pointers?
>>
>>
>> Antoine Rousseau
>>   http://www.metalu.net[http://metalu.net] __
>> http://www.metaluachahuter.com/[http://www.metaluachahuter.com/compagnies/al1-ant1/]
>>
>>
>> Le ven. 7 sept. 2018 à 19:20, Christof Ressi > [mailto:christof.re...@gmx.at]> a écrit :> you mean like the little
>> square of the canvas object?
>>
>> kind of, except that my_canvas only shows the square when the object is
>> selected. of course that's also possible! my idea was to show it when you
>> hover the object in editmode, so you don't have to explicitly select the
>> object to see where to make the connections.
>>
>>
>> Gesendet: Freitag, 07. September 2018 um 18:43 Uhr
>> Von: "Antoine Rousseau" mailto:anto...@metalu.net]>
>> An: "Christof Ressi"
>> mailto:christof.re...@gmx.at]>
>> Cc: Pd-list mailto:Pd-list@lists.iem.at]>
>> Betreff: Re: Re: [PD] Slider/Knob
>>
>> a visual hint (i.e. draw the rect borders and the iolets)- but only when
>> the user hovers over the knob while the glist is in editmode
>>
>> you mean like the little square of the canvas object? yes, I like the
>> idea. I'll try this soon, thanks!
>>
>>
>> Antoine Rousseau
>>   http://www.metalu.net[http://www.metalu.net][http://metalu.net[
>> http://metalu.net]] __
>> http://www.metaluachahuter.com/[http://www.metaluachahuter.com/compagnies/al1-ant1/][http://www.metaluachahuter.com/%5Bhttp://www.metaluachahuter.com/compagnies/al1-ant1/%5D]
>> <http://www.metaluachahuter.com/%5Bhttp://www.metaluachahuter.com/compagnies/al1-ant1/%5D%5Bhttp://www.metaluachahuter.com/%5Bhttp://www.metaluachahuter.com/compagnies/al1-ant1/%5D%5D>
>>
>>
>> Le ven. 7 sept. 2018 à 17:31, Christof Ressi > [mailto:christof.re...@gmx.at][mailto:christof.re...@gmx.at[mailto:
>> christof.re...@gmx.at]]> a écrit :Hi, to be honest, I never found it to
>> be a big problem. I'm not too sure about the three outlet solution, I
>> think
>> it's indeed a bit far-stretched :-) what I would suggest is to give the
>> user a visual hint (i.e. draw the rect borders and the iolets)- but only
>> when the user hovers over the kno

Re: [PD] distinction Pd lingo: abstraction, subpatch, subwindow

[katja]

Long ago I've learned (from the FLOSS manual?) about 'encapsulated'
subpatch' as opposed to abstraction. Beautiful word, but a bit long. When
compared to a language like C, an encapsulated subpatch is the equivalent
of code folding, visually hiding the content. Whereas an abstraction is
like a function that you call through its name, possibly passing arguments.

Katja

On Sun, Aug 12, 2018 at 12:54 AM, Miller Puckette  wrote:

> I think the best terminology is "sub-patch" for eitehr an abstraction or
> for a one-off subpatch.  (But then we probably need a better term for
> 'one-off';
> maybe 'ad hoc'?
>
> cheers
> Miller
>
> On Tue, Aug 07, 2018 at 01:44:18PM +0200, Max wrote:
> > In the Pd documentation the word
> >
> > abstraction is found 1859 times
> > subpatch is found 2142 times
> > sub-patch is found 45 times
> > subwindow is found 24 times
> > sub-window is found 1 time (that's in the html document, where it occurs
> 3
> > times hyphenated and 1 time not hyphenated)
> >
> > For reference: Definitions of the terms subpatch and abstraction can be
> > found in paragraphs 2.7 and 2.7.1 of the documentation.
> >
> > The terms however are consistently used inconsistent.
> >
> > in 2.7.2 "Graph-on-parent subpatches" the illustration shows an
> abstraction,
> > not a subpatch. The text first talks about an abstraction and then
> > continues: "When the sub-patch is closed, all controls in it appear on
> the
> > object instead; so the number box in the sub-patch in the example above
> is
> > the same one as you see in the box. "
> >
> > Even weirder, there is a definition of the term "abstraction" in the
> > clone-help.pd which goes as follows: "a patch loaded as an object in
> another
> > patch"
> > but in the same patch the clones abstraction is named
> "clone-subpatch.pd".
> >
> > Is there something I am missing here?
> >
> > m.
> >
> > On 05.08.2018 12:01, Max wrote:
> > > OK, let me try myself, please correct me:
> > >
> > > An abstraction is a Pd patch which is used like an object in another Pd
> > > patch.
> > >
> > > A subpatch is saved within the main patch and is constructed with [pd
> > > {name}]. Multiple subpatches with the same name may coexist.
> > >
> > > Subwindow is the umbrella term for both of the prior terms.
> > >
> > > If someone can confirm that the above definition is true, I will make
> > > some pull requests to the documentation/ help files since it isn't
> > > consistent. The pd~-help for example.
> > >
> > >
> > > On 04.08.2018 14:05, Max wrote:
> > > > In the helpfiles and on this list the three words
> > > >
> > > > 'abstraction'
> > > > 'subpatch' or 'sub-patch'
> > > > 'subwindow'
> > > >
> > > > are used. could someone provide a definition of those? I suspect
> > > > they aren't used in a consistent way throughout the documentation.
> > > >
> > > > 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
> >
> >
> > ___
> > 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] iemguts for mac-ppc

[katja]

On Sun, May 13, 2018 at 2:01 PM, <ro...@dds.nl> wrote:

> katja schreef op 12-05-2018 12:32:
>
>> On Fri, May 11, 2018 at 4:08 PM, <ro...@dds.nl> wrote:
>>
>> hi,
>>>
>>> trying to install an up-to-date IEMGUTS for/on an old mac-ppc.
>>> (because deken presents an old version)
>>>
>>> the readme.txt of IEMGUTS says:
>>>
>>> installation::
>>> --
>>> #2> make
>>> #3> make install
>>>
>>> "make" seems to work allright,
>>> but "make install" gives 'no rule for make target install'
>>>
>>
>> This behavior isn't reproducible for me (on Linux). Can you run
>> command 'make vars' and check the following:
>>
>> 1. What is the value of 'version' (gives the makefile version)?
>>
>> 2. Do values of variables 'executables', 'datafiles' and 'datadirs'
>> correspond with actual files in the source tree?
>>
>
>
> @ katja,
>
> thanks to your questions the solution was simple.
>
> i did start inside the /src folder of iemguts, where is also a makefile.
> 'make vars' like 'make install' gave 'no rule...',
> while 'make' did work (like i said in the first mail).
>
> changing to the main folder did the trick.
>

The README could mention that, report an issue on the repo if you want.


> so it works, but (small nuisance) the install does not take the path
> that's in my preferences.
>

True, the makefile doesn't read Pd's preferences but uses platform specific
default paths. To install at your preferred location, use variable PDLIBDIR
as absolute or relative path to the parent dir for your pd library /
libraries:

make install PDLIBDIR=


Katja


> dank anyway,
> rolf
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] iemguts for mac-ppc

[katja]

On Fri, May 11, 2018 at 4:08 PM, <ro...@dds.nl> wrote:

> hi,
>
> trying to install an up-to-date IEMGUTS for/on an old mac-ppc.
> (because deken presents an old version)
>
> the readme.txt of IEMGUTS says:
>
> installation::
> --
> #2> make
> #3> make install
>
>
> "make" seems to work allright,
> but "make install" gives 'no rule for make target install'
>

This behavior isn't reproducible for me (on Linux). Can you run command
'make vars' and check the following:

1. What is the value of 'version' (gives the makefile version)?

2. Do values of variables 'executables', 'datafiles' and 'datadirs'
correspond with actual files in the source tree?

Katja


what to do/change?
>
> rolf
>
>
> ___
> 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] [solved] glitches when streaming UDP

[katja]

On Wed, Jan 31, 2018 at 9:32 AM, katja <katjavet...@gmail.com> wrote:

>
>
> On Wed, Jan 31, 2018 at 1:22 AM, Roman Haefeli <reduz...@gmail.com> wrote:
>
>>
>>
>> I'm a bit unsure about the -nosleep option. What is it supposed to do?
>> I thought it would make Pd burn as many CPU cycles as it can get. And
>> your mail from 2015 suggests a similar behavior. I run it like this:
>>
>> pd -noprefs -nosleep -rt -jack -channels 2
>>
>> and it still only runs at 3% of a core with the [adc~]-[dac~] patch.
>> This is with Pd-0.48-1 (git 3417d9036).
>>
>
> When running pd Pd-0.48-1 with option -nosleep on my core2 machine, CPU
> load is 100% on one (switching) core. Seems like the -nosleep option does
> not have the same effect on all hardware. That may be an indicator of the
> underlying problem causing audio drop out.
>

Sorry, forgot to mention that this is with Xubuntu 16.04.


> Katja
>
>
>
>> Roman
>>
>>
>>
>>
>> ___
>> 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] [solved] glitches when streaming UDP

[katja]

On Wed, Jan 31, 2018 at 1:22 AM, Roman Haefeli <reduz...@gmail.com> wrote:

>
>
> I'm a bit unsure about the -nosleep option. What is it supposed to do?
> I thought it would make Pd burn as many CPU cycles as it can get. And
> your mail from 2015 suggests a similar behavior. I run it like this:
>
> pd -noprefs -nosleep -rt -jack -channels 2
>
> and it still only runs at 3% of a core with the [adc~]-[dac~] patch.
> This is with Pd-0.48-1 (git 3417d9036).
>

When running pd Pd-0.48-1 with option -nosleep on my core2 machine, CPU
load is 100% on one (switching) core. Seems like the -nosleep option does
not have the same effect on all hardware. That may be an indicator of the
underlying problem causing audio drop out.

Katja



> 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] [solved] glitches when streaming UDP

[katja]

Found this in the archives, maybe it is somewhat similar: in the early
Raspberry Pi days core switching seemed to be a problem for Pd and it could
be solved by using 'taskset'. See:

https://lists.puredata.info/pipermail/pd-list/2015-02/109189.html

The CPU switching problem went away 'by itself' after a Raspbian update,
but it was probably hardware specific.

On Wed, Jan 31, 2018 at 12:31 AM, katja <katjavet...@gmail.com> wrote:

> What happens when running Pd with option -nosleep? I vaguely remember
> having problems with CPU scaling which could be 'resolved' with that
> option. People smarter than me pointed to other solutions where you could
> reserve a specific core for the Pd process. But I'm unable to retrieve that
> information.
>
> On Wed, Jan 31, 2018 at 12:08 AM, Roman Haefeli <reduz...@gmail.com>
> wrote:
>
>> On Die, 2018-01-30 at 23:31 +0100, Dan Wilcox wrote:
>> > I agree. I recorded 8 channel multitrack from Pd to Ardour using a
>> > single core Thinkpad back in the day with no drop outs.
>> >
>> > You could try running Pd with a different nice level. Even though it
>> > has "realtime priority" it sometimes helps to cue the scheduler a
>> > little more directly.
>>
>> 'pd -rt -jack' runs with a nice level of 0, so does jackd and ardour. I
>> tried giving it higher priority up (or should I say: down?) to -10, but
>> it didn't change the situation. Also, it seems  to me that it's not a
>> problem of priorities between several processes. The fact that burning
>> CPU cycles with _another_ process helps makes me think the problem
>> rather is that resources are not made ready quickly enough.
>>
>> Roman
>>
>>
>> > > On Jan 30, 2018, at 11:21 PM, pd-list-requ...@lists.iem.at wrote:
>> > >
>> > > Interestingly, setting CPU scaling governor to performance is not
>> > > enough for Pd (it is for other applications, though). When doing
>> > > that
>> > > for each core, they all run at maximum speed. However, it doesn't
>> > > help
>> > > with making Pd glitch free. I really have to put some load on
>> > > them.
>> > >
>> > > This confirms what I suspected for while now: The advanced power
>> > > saving
>> > > features of modern CPUs don't really help for realtime audio.
>> > >
>> > > I wonder what softwares like Ardour do differently to not fall
>> > > victim
>> > > of aggressive power saving.
>> > >
>> > > Having a constantly running fan is also not an ideal situation. I
>> > > don't
>> > > care about increased power consumption at this point.  Maybe there
>> > > is a
>> > > less invasive way to keep the CPU busy?
>> > 
>> > Dan Wilcox
>> > @danomatika
>> > danomatika.com
>> > robotcowboy.com
>> >
>> >
>> >
>>
>> ___
>> 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] [solved] glitches when streaming UDP

[katja]

What happens when running Pd with option -nosleep? I vaguely remember
having problems with CPU scaling which could be 'resolved' with that
option. People smarter than me pointed to other solutions where you could
reserve a specific core for the Pd process. But I'm unable to retrieve that
information.

On Wed, Jan 31, 2018 at 12:08 AM, Roman Haefeli  wrote:

> On Die, 2018-01-30 at 23:31 +0100, Dan Wilcox wrote:
> > I agree. I recorded 8 channel multitrack from Pd to Ardour using a
> > single core Thinkpad back in the day with no drop outs.
> >
> > You could try running Pd with a different nice level. Even though it
> > has "realtime priority" it sometimes helps to cue the scheduler a
> > little more directly.
>
> 'pd -rt -jack' runs with a nice level of 0, so does jackd and ardour. I
> tried giving it higher priority up (or should I say: down?) to -10, but
> it didn't change the situation. Also, it seems  to me that it's not a
> problem of priorities between several processes. The fact that burning
> CPU cycles with _another_ process helps makes me think the problem
> rather is that resources are not made ready quickly enough.
>
> Roman
>
>
> > > On Jan 30, 2018, at 11:21 PM, pd-list-requ...@lists.iem.at wrote:
> > >
> > > Interestingly, setting CPU scaling governor to performance is not
> > > enough for Pd (it is for other applications, though). When doing
> > > that
> > > for each core, they all run at maximum speed. However, it doesn't
> > > help
> > > with making Pd glitch free. I really have to put some load on
> > > them.
> > >
> > > This confirms what I suspected for while now: The advanced power
> > > saving
> > > features of modern CPUs don't really help for realtime audio.
> > >
> > > I wonder what softwares like Ardour do differently to not fall
> > > victim
> > > of aggressive power saving.
> > >
> > > Having a constantly running fan is also not an ideal situation. I
> > > don't
> > > care about increased power consumption at this point.  Maybe there
> > > is a
> > > less invasive way to keep the CPU busy?
> > 
> > Dan Wilcox
> > @danomatika
> > danomatika.com
> > robotcowboy.com
> >
> >
> >
>
> ___
> 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] fft~ bug in Pd-0.46-7-64bit.app on OSX

[katja]

Minimum FFT size is still not fixed in pd 0.48-1test3. I verified that
4 point works as expected for all FFT objects (fft~, ifft~, rfft~ and
rifft~) if this conditional check is changed in function ooura_init():

"if (n < 64)" becomes "if (n < 4)"

By the way I used a 16 point FFT to quickly test a wild idea. Without
the small FFT it would have taken much more time to reveal that it was
indeed a fata morgana. So, yes, very useful (as a time-saver in this
case).

Katja

On Mon, Oct 19, 2015 at 8:26 PM, Miller Puckette <m...@ucsd.edu> wrote:
> I'm not sure, but I think I had limited it to 64 because some older FFT
> package I was using had that limit.  I'm not sure but I think the rfft
> objects require at least 4 points to work properly.  So perhaps it would be
> OK to impose 4 as a minimum for all the FFT objects.
>
> In any case, there certainly should have been an error message... it simply
> never occurred to me that anyone would want an FFT of fewer than 64 points :)
>
> M
>
>
> On Sat, Oct 17, 2015 at 10:59:00AM +0200, katja wrote:
>> OOURA's cdft and rdft function descriptions clearly state that FFT
>> size 2 is the minimum. Maybe the data permutation is trickier for
>> block size < 64. The old arrangement was weird, you don't get an array
>> with complex numbers, but the imaginary output appearing in reversed
>> order after the real output. Because the FFT functions are in Pd's API
>> it is still rearranged that way (and the object has to rearrange again
>> when copying to the outlet). I don't know if this hampers FFT size <
>> 64, this is just a wild guess.
>>
>> Anyway I don't like this limitation at all. Small FFT sizes can be
>> indispensable in rigid tests and experiments.
>>
>> Katja
>>
>> Katja
>>
>> On Sat, Oct 17, 2015 at 4:17 AM, Matt Barber <brbrof...@gmail.com> wrote:
>> > Looking closer, it appears the OOURA fft has special routines for n<64...
>> > but it uses those routines regularly as subroutines in larger ffts. In any
>> > case it looks like the smaller block sizes are intended to be usable in the
>> > code itself, but Miller must've had a reason not to trust them. Here's the
>> > main OOURA complex fourier transform subroutine, which calls a bunch of
>> > others, which all call smaller ones. The Pd prologue code would make sure
>> > that none of the smaller cases at the bottom would ever be called.
>> >
>> > ===
>> > void cftfsub(int n, FFTFLT *a, int *ip, int nw, FFTFLT *w)
>> > {
>> > void bitrv2(int n, int *ip, FFTFLT *a);
>> > void bitrv216(FFTFLT *a);
>> > void bitrv208(FFTFLT *a);
>> > void cftf1st(int n, FFTFLT *a, FFTFLT *w);
>> > void cftrec4(int n, FFTFLT *a, int nw, FFTFLT *w);
>> > void cftleaf(int n, int isplt, FFTFLT *a, int nw, FFTFLT *w);
>> > void cftfx41(int n, FFTFLT *a, int nw, FFTFLT *w);
>> > void cftf161(FFTFLT *a, FFTFLT *w);
>> > void cftf081(FFTFLT *a, FFTFLT *w);
>> > void cftf040(FFTFLT *a);
>> > void cftx020(FFTFLT *a);
>> > #ifdef USE_CDFT_THREADS
>> > void cftrec4_th(int n, FFTFLT *a, int nw, FFTFLT *w);
>> > #endif /* USE_CDFT_THREADS */
>> >
>> > if (n > 8) {
>> > if (n > 32) {
>> > cftf1st(n, a, [nw - (n >> 2)]);
>> > #ifdef USE_CDFT_THREADS
>> > if (n > CDFT_THREADS_BEGIN_N) {
>> > cftrec4_th(n, a, nw, w);
>> > } else
>> > #endif /* USE_CDFT_THREADS */
>> > if (n > 512) {
>> > cftrec4(n, a, nw, w);
>> > } else if (n > 128) {
>> > cftleaf(n, 1, a, nw, w);
>> > } else {
>> > cftfx41(n, a, nw, w);
>> > }
>> > bitrv2(n, ip, a);
>> > } else if (n == 32) {
>> > cftf161(a, [nw - 8]);
>> > bitrv216(a);
>> > } else {
>> > cftf081(a, w);
>> > bitrv208(a);
>> > }
>> > } else if (n == 8) {
>> > cftf040(a);
>> > } else if (n == 4) {
>> > cftx020(a);
>> > }
>> > }
>> > ===
>> >
>> > On Fri, Oct 16, 2015 at 7:43 PM, Robert Esler <rob...@urbanstew.org> wrote:
>> >>
>> >> Sorry I checked your patch again.  I get the same behavio

Re: [PD] Can't load external I put together and want to test

[katja]

On Wed, Dec 27, 2017 at 7:52 PM, IOhannes m zmölnig <zmoel...@iem.at> wrote:
> On 12/27/2017 07:05 PM, Christof Ressi wrote:
>> this strikes me as odd. in C, funtion declarations/definitions are extern by 
>> default, i.e. there shouldn't be any difference between
>> void foo(void) { ... }
>> and
>> extern void foo(void) {...}
>>
>> in fact, I haven't seen a single Pd external source file where the setup 
>> function was explicitly marked 'extern'.
>>
>> could it be that your setup function was accidentally marked as 'static'? 
>> how did you build your external?
>>
>
> more likely, your compiler/linker defaults to not exporting any symbols
> that are not explicitely eported.
> reading the changelog and README.Debian that comes with your compiler
> docs (look out for /usr/share/doc/gcc*/) might help.
>

When a makefile or environment specifies ld flag -visibility=hidden,
gcc does not export symbols except those declared with
"__attribute__((visibility("default")))" (on Linux / OSX) or
"__declspec(dllexport)" (on Windows).
(https://gcc.gnu.org/wiki/Visibility, this doc is about C++ but it
works the same for C). Such attributes should be used for the setup
function of a Pd external in that case. I haven't found any docs
saying that explicit "extern" can serve a similar purpose of
overriding a visibility setting or default.

Katja


> gfamdsr
> IOhannes
>
>
> ___
> 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] Can't load external I put together and want to test

[katja]

(on top of my head) even when an executable is found by pd, some
things can still go wrong;

- a symbol is not found
- required arguments aren't supplied

If a (function) symbol is not found, I think that pd would mention
that in verbose mode. Is there no relevant warning at all?

Katja

On Mon, Dec 25, 2017 at 10:32 PM, Alexandros <adr...@gmail.com> wrote:
> I just put together some pieces of Pd's source code to make an external, and
> even though it compiles without a problem (using Katja's
> Makefile.pdlibbuilder), Pd just can't load it. Using verbose mode I see that
> Pd tries a bunch of directories, and even though this line is included:
>
> tried
> /home/alexandros/Documents/Pd/externals/sync_phasor~/sync_phasor~.pd_linux
> and succeeded
>
> Pd keeps on trying to find it, and there are more failure lines after that
> and eventually the object can't be created. How can I solve this?
>
> I'm on Ubuntustudio 17.10 with Pd-0.48-0
>
>
> ___
> 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] midifixes testing

[katja]

In pd 0.48-1test3 release on github (but called 0.48.1-1test2 in
'About Pd') a [midiclkin] object still tries to instantiate in 'list
of objects', that is, doc/5.reference.

Katja

On Mon, Dec 4, 2017 at 1:40 PM, Dan Wilcox <danomat...@gmail.com> wrote:
> For MIDI heads out there who can build Pd, can y'all test the current git
> master?
>
> My midifixes PR was merged into master and it would be good to get some
> testing on it.
>
> I developed a tool to test things which might be handy:
> https://github.com/danomatika/miditester
>
> 
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
>
>
>
>
> ___
> 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] RPI 3 USB audio performance?

[katja]

Dan, the reason I focused on small devices is that RPi is still prone
to loose USB connection in cases of short voltage dip. The larger
pro-sumer audio interfaces draw a lot of current which adds to the
risk of those dreaded brown out moments. That is why I discarded the
idea of using my favorite interface, Mackie Onyx Black Jack, in a
wearable RPi setup. From the top of my head: the Mackie draws some 500
mA, an iMic ~45 mA and a cheap skype dongle ~10 mA.

Katja

On Tue, Oct 10, 2017 at 6:51 PM, Dan Wilcox <danomat...@gmail.com> wrote:
> Katja, that's some good research especially considering the size of those
> interfaces. I'm mainly sticking with larger boxes which have XLR and jack
> inputs.
>
> How is the performance overall ala dropouts, latency, etc?
>
> I ran into issues with RPIs before that simply could not handle asynchronous
> with a more pro-sumer USB audio interface, leading to constant dropouts when
> running full duplex. I'm mainly using older but very solid Roland boxes
> (UA-25 and UA-25EX) which are stereo duplex USB 1.1, fully standard USB
> audio compliant, and work with pretty much anything including my iPhone.
>
> I'm asking as I'd rather not go through the process of setting up a new
> system on yet another embedded device and get *less* performance than with
> my 500 Mhz wearable 10 years ago. :)
>
>
> On Oct 10, 2017, at 5:49 PM, katja <katjavet...@gmail.com> wrote:
>
> What I found is, small USB audio dongles don't process low frequencies
> well because they use too small capacitors. This can be improved by
> DIY soldering. Also some of them do a bad job in noise shaping,
> leaving quantization noise in audible range. That is something you
> can't improve. Here is a page describing some of my findings:
>
> http://www.katjaas.nl/audiodongle/audiodongle.html
>
> Good old Griffin iMic is better than the dongles I tried. But it is
> nice to hack a dongle and make it a tiny bit better. Maybe it's time
> to design our own audio dongle.
>
> Katja
>
> On Tue, Oct 10, 2017 at 3:41 PM, Dan Wilcox <danomat...@gmail.com> wrote:
>
> For those of you using RPI 3s with Pd, how is the audio performance using a
> standard stereo USB audio interface?
>
> I'm talking simple, USB 1.1 full duplex at 16 bit, nothing fancy. No special
> RPI-only backpack boards or GPIO audio debs, just regular usb audio devices.
>
> 
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
>
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
>
> 
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
>
>
>

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

Re: [PD] RPI 3 USB audio performance?

[katja]

What I found is, small USB audio dongles don't process low frequencies
well because they use too small capacitors. This can be improved by
DIY soldering. Also some of them do a bad job in noise shaping,
leaving quantization noise in audible range. That is something you
can't improve. Here is a page describing some of my findings:

http://www.katjaas.nl/audiodongle/audiodongle.html

Good old Griffin iMic is better than the dongles I tried. But it is
nice to hack a dongle and make it a tiny bit better. Maybe it's time
to design our own audio dongle.

Katja

On Tue, Oct 10, 2017 at 3:41 PM, Dan Wilcox <danomat...@gmail.com> wrote:
> For those of you using RPI 3s with Pd, how is the audio performance using a
> standard stereo USB audio interface?
>
> I'm talking simple, USB 1.1 full duplex at 16 bit, nothing fancy. No special
> RPI-only backpack boards or GPIO audio debs, just regular usb audio devices.
>
> 
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
>
>
>
>
> ___
> 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] MARG (Was: Sensors2OSC mapping challenge)

[katja]

Max, I don't know of a Pd project in this field, but there's a good
reason to do sensor mixing (beit IMU or AHRS) on the platform that
reads the sensors rather than in a Pd patch or external. The filter /
mixer works best when sensor data is read at a higher sample rate than
you may need the orientation data. For example, an Arduino Pro Micro
(16 MHz processor) can do IMU mixing at ~400 Hz which is just a decent
sample rate for the purpose of filtering sensor noise. For parameter
control I don't really need the data at that rate so I send midi
messages at a lower rate (could be OSC instead of midi). That
minimizes traffic over USB but also a saves lot of function calls in
Pd.

On the other hand it would be nice to do it in a Pd patch or external
for educational reasons or better reusability. By the way Sebastian
Madgwick's current work on AHRS is in this repository:

https://github.com/xioTechnologies/Fusion

Katja

On Sun, Aug 20, 2017 at 9:02 PM, Max <abonneme...@revolwear.com> wrote:
> Attached is the C code from the paper linked below.
> Before I try, should I attempt to make this in Pd as an abstraction or just
> take this c code and see if I can turn it into an external?
>
> Or maybe someone has already done it?
>
>
> On 2017년 07월 27일 09:17, katja wrote:
>>
>> Hi Max,
>>
>> To emulate 3D orientation from gyro, accelerometer and compass data is
>> most efficiently done using a 'quaternion filter'. Sebastian Madgwick
>> has popularized the method, see
>> http://x-io.co.uk/open-source-imu-and-ahrs-algorithms/. I use
>> Madgwicks implementation of Mahoney's method, for Arduino based
>> 'electronic hands', and found that Mahoney's algorithm for IMU sensors
>> (gyro and accelerometer only) worked much better than Madgwick's own
>> algorithm. But I had to make a few modifications, based on Kris
>> Winer's work (https://github.com/kriswiner).
>>
>> Katja
>>
>> On Tue, Jul 25, 2017 at 11:13 PM, Max <abonneme...@revolwear.com> wrote:
>>>
>>> Made a quick little video
>>> https://vimeo.com/226958567
>>> the described issue is still there.
>>>
>>> Background on the problem:
>>>
>>> https://stackoverflow.com/questions/27106607/get-rotation-and-display-in-degrees
>>>
>>> https://stackoverflow.com/questions/15315129/convert-magnetic-field-x-y-z-values-from-device-into-global-reference-frame#15317814
>>>
>>>
>>>
>>> On 2017년 07월 08일 23:16, Max wrote:
>>>>
>>>>
>>>> I've played around with the Android app Sensors2OSC [1] and was trying
>>>> to
>>>> just map the senors to a virtual model of a phone.
>>>> I was able to get the axis individually mostly behaving correctly, but
>>>> as
>>>> soon as the phone moves around in more than one way, it is doing weird
>>>> things. I started to wonder if it is only my phone though.
>>>>
>>>> At https://github.com/mxa/GemVR the patch ReceiveSensors2OSC.pd has
>>>> everything ready to map the senor data to the Gem model.
>>>>
>>>> I'd be curious to see if it is possible to let it behave correctly.
>>>>
>>>> [1] https://sensors2.org/osc/
>>>>
>>>> ___
>>>> 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] Sensors2OSC mapping challenge

[katja]

Hi Max,

To emulate 3D orientation from gyro, accelerometer and compass data is
most efficiently done using a 'quaternion filter'. Sebastian Madgwick
has popularized the method, see
http://x-io.co.uk/open-source-imu-and-ahrs-algorithms/. I use
Madgwicks implementation of Mahoney's method, for Arduino based
'electronic hands', and found that Mahoney's algorithm for IMU sensors
(gyro and accelerometer only) worked much better than Madgwick's own
algorithm. But I had to make a few modifications, based on Kris
Winer's work (https://github.com/kriswiner).

Katja

On Tue, Jul 25, 2017 at 11:13 PM, Max <abonneme...@revolwear.com> wrote:
> Made a quick little video
> https://vimeo.com/226958567
> the described issue is still there.
>
> Background on the problem:
> https://stackoverflow.com/questions/27106607/get-rotation-and-display-in-degrees
> https://stackoverflow.com/questions/15315129/convert-magnetic-field-x-y-z-values-from-device-into-global-reference-frame#15317814
>
>
>
> On 2017년 07월 08일 23:16, Max wrote:
>>
>> I've played around with the Android app Sensors2OSC [1] and was trying to
>> just map the senors to a virtual model of a phone.
>> I was able to get the axis individually mostly behaving correctly, but as
>> soon as the phone moves around in more than one way, it is doing weird
>> things. I started to wonder if it is only my phone though.
>>
>> At https://github.com/mxa/GemVR the patch ReceiveSensors2OSC.pd has
>> everything ready to map the senor data to the Gem model.
>>
>> I'd be curious to see if it is possible to let it behave correctly.
>>
>> [1] https://sensors2.org/osc/
>>
>> ___
>> 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] accoustic guitar chord detection

[katja]

Jamie Bullock, in a paper about his libXtract, reports good results
with piano chord detection. Find the paper and library via his
projects page:

http://jamiebullock.com/projects

Details of the neural network he uses for training are not described
in the paper, you'll probably need to ask him for more info.

Katja

On Wed, Mar 29, 2017 at 2:51 AM, Alexandre Torres Porres
<por...@gmail.com> wrote:
> howdy, getting involved in a research that needs to detect notes from guitar
> chords (no hex pickup solutions, unfortunately). No need to do anything
> fancy with the spectra, or process it in any way like with celemony
> melodyne's DNA stuff. Do any of you know of some nice stuff done in Pd or
> Max or SC or whatever on that?
>
> thanks
>
> ___
> 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] Running Pd with real-time priority

[katja]

Which Pd version do you run? I remember having the same issue with Pd
on Raspberry Pi some years ago. Pd at that time asked for rtprio 99
and didn't get it with jackd default settings. In response Miller has
then changed Pd's rtprio requirement to 95 (I don't remember which Pd
version exactly, it was probably around 0.45). If the Odroid image
ships an old Pd, setting rtprio 99 could make the difference.

Katja

On Wed, Mar 29, 2017 at 1:16 AM, Alexandros Drymonitis <adr...@gmail.com> wrote:
> When running Pd, it is supposed to run with real-time priority by default,
> right?
>
> When launching Pd from the terminal, you usually get this printed:
> priority 6 scheduling enabled.
> priority 8 scheduling enabled.
>
> I'm running Pd on an Odroid-U3, and launching Pd from the terminal doesn't
> print anything like this.
> I'm using Pd with jack, which I run with real-time priority (I'm using
> Qjackctl and I'm clicking on the Realtime tick-box). I have the following
> both in /etc/security/limits.conf and in /etc/security/limits.d/audio.conf:
>
> @audio   -  rtprio 95
> @audio   -  memlockunlimi
> ted
> @audio   -  nice  -19
>
> The user odroir (which is the default user in the Odroid image) is a member
> of the audio group. What am I missing here? Is Pd running with real-time
> priority indeed, or do I need to do something more than that to run with
> real-time priority?
>
> ___
> 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] defaults interface on 10.8

[katja]

Hi Jonathan,

Sorry for the delay, the plutil manpage for 10.8.5 says about format
for the '-convert' flag:

fmt is one of: xml1, for version 1 of the XML plist format
binary1, for version 1 of the binary plist format
json, for the JSON format

Among the additional options is:

-r   For JSon, add whitespace and indentation to make the output mor
human-readable.

Katja

On Wed, Mar 15, 2017 at 8:08 PM, Jonathan Wilkes <jancs...@yahoo.com> wrote:
> Thanks for the report, katja.
>
> It looks like we can use 'plutil' instead.
>
> Does the manpage for 'plutil' in 10.8 include 'json' as a possible
> format for the '-convert' flag?
>
> -Jonathan
>
> On Wed, Mar 15, 2017 at 12:57 AM, Jonathan Wilkes <jancs...@yahoo.com>
> wrote:
>
>
>
>>> On Mon, Mar 13, 2017 at 2:22 PM, Jonathan Wilkes via Pd-list
>>
>>
>> <pd-list@lists.iem.at> wrote:
>>>> Hello list,
>>>>
>>>> Can someone on OSX 10.8 please run the following command:
>>>> defaults export /Library/Preferences/SystemConfiguration/preferences -
>>
>>> Trying this on OSX 10.8.5.
>>
>> Just to be clear-- did you type the exact command I specified above?  If
>> so, what happened?
>
>
> With the command as you specify, but also with command 'defaults'
> without argument, it responds with:
>
> "Command line interface to a user's defaults.
> Syntax:
> 'defaults' [-currrentHost | -host ] followed by one of the
> following:
> [...]"
>
> Then follows the list with command options (read, read-type, write,
> rename, delete, domains, find) and explanations. In other words,
> 'defaults' without argument or with argument 'export' are not valid
> options on this system (10.8.5). Compare the issue described here:
>
> https://github.com/kcrawford/dockutil/issues/17
>
> Can you think of another approach to get what you want, that I can
> test on 10.8.5?
>
> Katja
>
>
>

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

Re: [PD] defaults interface on 10.8

[katja]

On Mon, Mar 13, 2017 at 2:22 PM, Jonathan Wilkes via Pd-list
<pd-list@lists.iem.at> wrote:
> Hello list,
>
> Can someone on OSX 10.8 please run the following command:
> defaults export /Library/Preferences/SystemConfiguration/preferences -

Trying this on OSX 10.8.5. Command 'defaults' needs an argument;
'read', 'write', 'rename', 'domains' are among the options, but not
'export'. For example:

$ defaults read org.puredata.pd

gives the preferences for pd as a list between curly braces. I don't
see how to get the /Library/Preferences... etc. into the command?

Katja


>
> And tell me what happens:
> a) it outputs some xml that ends with ""
> b) it outputs the same exact thing as running `defaults` with no arguments
>
> Thanks,
> Jonathan
>
> ___
> 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] repackaging externals on Deken

[katja]

On Mon, Jan 23, 2017 at 5:00 AM, Liam Goodacre <liamg...@hotmail.com> wrote:
>
>
> Also, can you elaborate on your second-last paragraph? I don't follow this.
>

I'm sorry that this discussion got complicated but I may not have
grasped your intention. From your original mail:

"Is it feasible / acceptable to bundle all the externals I'm using
into a folder and distribute them along with the main Context
package?"

That made me think you want to redistribute parts of libraries (only
the externals you need), in which case you'd need modified build
systems that don't try to build the omitted externals. Or do you mean
to bundle complete libraries pre-built for one or more platforms? Or
binaries without source & build system (which is not encouraged, see
https://github.com/pure-data/deken/issues/88)?

In any case, I still think for an alpha test release you need not
realize the one click all inclusive dream yet. Feedback from alpha
testers may give you more insights about dependency caveats than you
can get from a hypothetical viewpoint. Did you successfully build the
missing iemguts libraries? If so you can upload them as deken packages
in their own right.

Katja


>
> ____
> From: katja <katjavet...@gmail.com>
> Sent: 21 January 2017 10:50
>
> To: Liam Goodacre
> Cc: PD list
> Subject: Re: [PD] repackaging externals on Deken
>
> Liam,
>
> Choosing a unique name for an external is indeed the best warranty to avoid 
> conflicts. Not only a future release of a dependency has the potential to 
> break your patch. An old release with a bug or missing feature can do that 
> too! It seems there's no way to force Pd loading the executable that sits in 
> your project tree (I would be very happy if someone can prove me wrong).
>
> So if you're concerned about versions of externals breaking your patch, you 
> could preventively fork them under a different and very specific name. Like 
> 'contxt_demux', 'contxt_initbang'. I won't advise against it because the 
> issue of name clash in pd is serious enough to consider all strategies, but 
> be aware that forking is a bit more involved than simply renaming an existing 
> binary (which won't do the trick as IOhannes has already mentioned).
>
> In either case (modified class names or not) a redistribution of GPL licensed 
> software should include the sources, and when you redistribute a subset you 
> need a customized build system.
>
> Note that I'm not advertising to redistribute, just detailing the 
> consequences. I learn from this discussion too.
>
>

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

Re: [PD] repackaging externals on Deken

[katja]

On Mon, Jan 23, 2017 at 1:04 PM, IOhannes m zmoelnig <zmoel...@iem.at> wrote:
> On 2017-01-21 11:50, katja wrote:

>> Not only a future release of a dependency has the potential to
>> break your patch. An old release with a bug or missing feature can do that
>> too! It seems there's no way to force Pd loading the executable that sits
>> in your project tree (I would be very happy if someone can prove me wrong).
>
> well iirc, you should be able to force-load a library by using it's
> "fully" qualified filename.
>
> that is, if you have an object [../context/iemguts/initbang], Pd
> wouldn't know how to create that, and start its library loading
> mechanism, eventually finding the ../context/iemguts/initbang.pd_linux
> file and loading it. doing so will - as a side effect - overwrite the
> constructor of "initbang", so any [initbang] instantiated therafter will
> be *this* version.
> (until Pd encounters an object [../cuntaxt/initbang] overwrite the
> constructor for "initbang" again).

Ah cool. So you make the path unambiguous by using the leading slash
(i.e. "./" for an object that sits next to the patch,
etcetera).

Happy! This method is great for test patches (unit tests, regression
tests) where you want to be sure to test the intended build. The
overwriting behavior isn't so elegant in some other cases though.

> i haven't tested how (and if) this works with [declare].

As far as I could check, [declare] does not have the effect of
overwriting a class.

>
> fgamsdr
> IOhannes


Katja

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

Re: [PD] repackaging externals on Deken

[katja]

Liam,

Choosing a unique name for an external is indeed the best warranty to avoid
conflicts. Not only a future release of a dependency has the potential to
break your patch. An old release with a bug or missing feature can do that
too! It seems there's no way to force Pd loading the executable that sits
in your project tree (I would be very happy if someone can prove me wrong).

So if you're concerned about versions of externals breaking your patch, you
could preventively fork them under a different and very specific name. Like
'contxt_demux', 'contxt_initbang'. I won't advise against it because the
issue of name clash in pd is serious enough to consider all strategies, but
be aware that forking is a bit more involved than simply renaming an
existing binary (which won't do the trick as IOhannes has already
mentioned).

In either case (modified class names or not) a redistribution of GPL
licensed software should include the sources, and when you redistribute a
subset you need a customized build system.

Note that I'm not advertising to redistribute, just detailing the
consequences. I learn from this discussion too.

Katja



On Fri, Jan 20, 2017 at 5:22 PM, Liam Goodacre <liamg...@hotmail.com> wrote:

> Dear all:
>
>
> Thanks for the detailed responses. My main interest here is, as Katja
> mentioned, the desire for a one-click-buy option (minus the "buy"). A
> secondary concern is that some future release of an external will change
> somehow break the patch, although this doesn't seem likely, given how
> slowly externals tend to move and the general commitment to backwards
> compatibility.
>
>
> I like Fred's idea of distributing two packages, one with- and one without
> externals*. However, I take Katja's point seriously that forcing two
> versions of the same file on the same disk could become problematic. A
> quick and dirty solution to this might be to rename all the external files
> that are uploaded in the Context deken package (ie. "demux.pd_linux" -->
> "demux2.pd_linux"). This would solve the problem as far as I can see,
> although it seems somehow wrong. What are people's thoughts about this?
>
>
> Two other points that are worth mentioning:
>
>
> 1. Context depends on [initbang] from iemguts 0.2.1. Last time I checked,
> the deken package for this was only available for Windows, not Linux or Mac.
>
>
> 2. I haven't used the [declare] object at all, given the warning in the
> help file against using it in abstractions. Instead, each external is
> declared in the object name.
>
>
>
> *Actually, four versions: one for Windows, Linux Mac, and one without
> externals.
>
> Liam
>
> --
> *From:* katja <katjavet...@gmail.com>
> *Sent:* 20 January 2017 15:29
> *To:* Liam Goodacre
> *Cc:* PD list
> *Subject:* Re: [PD] repackaging externals on Deken
>
> In the early days of Raspberry Pi I has a need to redistribute a few
> externals with PicoJockey, an ARMv6 targeted version of SliceJockey,
> because Pd-extended did not explicitly support the platform.
> PicoJockey includes a source tree with subsets of some external
> libraries plus a custom build system, and a binary build for ARMv6.
>
> This was in the pre-deken era, and while it would be technically
> possible to distribute PicoJockey (or any Pd project) in such a format
> via deken, I seriously doubt whether that it is a good idea. Libraries
> in deken are versioned, and so would be a project that depends on
> libraries. A project can only specify it's own version in the deken
> interface. Now imagine a project silently installs unspecified
> versions of other packages, or subsets thereof? Even when they reside
> in a subtree of the project, they will conflict with 'official'
> versions if not identical. This can be a source of confusion and
> frustration no matter how well you know Pd.
>
> I perfectly understand your desire for a 'one click buy', Liam. That's
> what I wanted for SliceJockey and PicoJockey as well. It's good for
> your project and also for the reputation of Pd when things work out of
> the box. But we have to recognize the fragility of a dependency chain.
> Even in the heyday of Pd-extended a library update could wreck your
> 'one click' project and leave people puzzled why it stopped working.
> In my experience, a Pd project with 'app convenience' is an illusion
> that can hold for only a while. When a project suggests to be
> self-containing, users are unaware of dependencies and clueless if
> something breaks.
>
> Externals are plugins no matter how they are distributed. Be sure to
> accurately and conspiciously document all dependencies of your
> project, on your project page and in the distribution. Then if
> something br

Re: [PD] repackaging externals on Deken

[katja]

In the early days of Raspberry Pi I has a need to redistribute a few
externals with PicoJockey, an ARMv6 targeted version of SliceJockey,
because Pd-extended did not explicitly support the platform.
PicoJockey includes a source tree with subsets of some external
libraries plus a custom build system, and a binary build for ARMv6.

This was in the pre-deken era, and while it would be technically
possible to distribute PicoJockey (or any Pd project) in such a format
via deken, I seriously doubt whether that it is a good idea. Libraries
in deken are versioned, and so would be a project that depends on
libraries. A project can only specify it's own version in the deken
interface. Now imagine a project silently installs unspecified
versions of other packages, or subsets thereof? Even when they reside
in a subtree of the project, they will conflict with 'official'
versions if not identical. This can be a source of confusion and
frustration no matter how well you know Pd.

I perfectly understand your desire for a 'one click buy', Liam. That's
what I wanted for SliceJockey and PicoJockey as well. It's good for
your project and also for the reputation of Pd when things work out of
the box. But we have to recognize the fragility of a dependency chain.
Even in the heyday of Pd-extended a library update could wreck your
'one click' project and leave people puzzled why it stopped working.
In my experience, a Pd project with 'app convenience' is an illusion
that can hold for only a while. When a project suggests to be
self-containing, users are unaware of dependencies and clueless if
something breaks.

Externals are plugins no matter how they are distributed. Be sure to
accurately and conspiciously document all dependencies of your
project, on your project page and in the distribution. Then if
something breaks, people will hopefully remember to check dependencies
and come back to your project page for info or updates. Some
dependencies are more susceptible to break than others (e.g.
unmaintained / orphaned / complicated / debated / forked libs).

You could use various distribution methods according to target
audience and release cycle. Why not start with an alpha test release
for vanilla + deken? If your project provides clear dependency
statements and include mechanisms like [declare] objects, your alpha
testers should be settled with a few deken clicks instead of just one.
If not... oh yeah... now I remember your problem with one external not
being up to date in deken. Is that a consideration for 'repackaging'?

Katja


On Wed, Jan 18, 2017 at 5:12 AM, Liam Goodacre <liamg...@hotmail.com> wrote:
> Hi all
>
>
> I'm starting to think about how to distribute the Context sequencer when it
> is ready (hopefully the day is not very far away).  Context is an
> abstraction, but it relies heavily on externals*. Ideally, I want it up on
> Deken, but I'm not sure what to do about the external packages. Is it
> feasible / acceptable to bundle all the externals I'm using into a folder
> and distribute them along with the main Context package? I'm hoping that
> this way the whole thing could be downloaded and installed in one click, but
> I want to make sure that there aren't any complications or license issues.
> Has external repackaging been done before?
>
>
> *The external libraries I'm using are:
>
>
> -cyclone
>
> -zexy
>
> -iemguts (including initbang)
>
> -moocow
>
> -flatgui
>
> -list-abs
>
>
> ___
> 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] Continuous Integration for Externals

[katja]

On Tue, Nov 29, 2016 at 12:07 PM, katja <katjavet...@gmail.com> wrote:

[...]
>
> From https://docs.travis-ci.com/user/customizing-the-build/, I
> understand that Travis CI is also a community build farm (but
> obviously bigger and more professional than we could organize in Pd
> community):
>
> 'Please take into account that Travis CI is an open source service and
> we rely on worker boxes provided by the community. So please only
> specify as big a matrix as you actually need.'

[...]

Oops, 'community' has a different meaning here than I imagined...
Travis virtual machines run on Google Compute Engine:

https://blog.travis-ci.com/2015-11-27-moving-to-a-more-elastic-future

Probably paid by private / commercial Travis users ($129 / month).
Same business model as Github after all.

Katja

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

Re: [PD] Continuous Integration for Externals

[katja]

On Tue, Nov 29, 2016 at 5:17 PM, Jonathan Wilkes <jancs...@yahoo.com> wrote:
>> Many of us don't have 'all' platforms available at their home or work
>
>
> place and we sorely miss the Pd-extended build farm with its nightly
> test builds. It seems useful to share knowledge and experience about
> an existing infrastructure like Travis.
>
> One option is "Giblab CI" which comes with Gitlab.  Essentially you define
> the build process
> with a yml file then set up "runners" on whatever machine(s) you want.  The
> runners can be
> on bare metal or a number of container environments-- docker, virtualbox,
> etc.
>
> Here's a (still rather crude) example:
> https://git.purrdata.net/jwilkes/purr-data/commit/326f08b8d6765482068c87e2516df45d8f165768/builds
>
> The nice thing about it is that each build machine just needs a single
> `gitlab-runner` instance running
> on it.  That process just polls the repo waiting for relevant commits,
> fetches (or clones) the repo, builds,
> and optionally uploads artifacts.
>
> In my case I'm using the virtualbox backend, so on each commit it clones a
> virtualbox snapshot,
> fetches the repo, builds, tests, and then uploads the resulting *.deb
> package.
>
> The OSX box always fails because I'm trying to build inside a virtualbox OSX
> guest running under OSX,
> and for some reason I cannot get OSX to ssh into an OSX guest.  Also for
> Windows you'd have to, well,
> have Windows. :)
>
> But even without Windows and OSX, having the CI speeds up the dev process by
> an order of magnitude.


It seems that with Gitlab CI you can configure 'runners' on your own
hardware for the project(s) that use it, right? So you can install
dependencies and don't need to start with a clean slate for every
build? That has several pro's and cons as compared with Travis. More
DIY, but still with a standardized API.

Katja

> Best,
> Jonathan

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

Re: [PD] Continuous Integration for Externals

[katja]

Before PdCon16~ I didn't even know about Travis. When IOhannes
explained that it is an online continuous integration tool, my naive
idea was 'can we use this to build our Pd libraries on 'all' platforms
and route the builds back to us?'

Many of us don't have 'all' platforms available at their home or work
place and we sorely miss the Pd-extended build farm with its nightly
test builds. It seems useful to share knowledge and experience about
an existing infrastructure like Travis.

From https://docs.travis-ci.com/user/customizing-the-build/, I
understand that Travis CI is also a community build farm (but
obviously bigger and more professional than we could organize in Pd
community):

'Please take into account that Travis CI is an open source service and
we rely on worker boxes provided by the community. So please only
specify as big a matrix as you actually need.'

There's an info page for 'complete beginners':
https://docs.travis-ci.com/user/for-beginners. A single page, is it so
easy? No, you really have to click that menu button in the right top
corner and read through a few dozen documentation pages to get an idea
what Travis can do, and how. All the info is there presented in a
user-friendly way. As we go and learn, we could make a Pd-related
summary or addition to this info. Yes I'm looking forward to Thomas
Mayer's 'Christmas / Chanukka gift to the community'!

If you build with Travis for a specific platform because you don't
have access to that machine or OS yourself, how can you test the build
products? Automated tests might be run on the Travis virtual machine
if you install Pd there.

But I'm also thinking of the following (not specifically related to
Travis): what if we would have a 'test section' in deken? Basically
meaning an optional 'test' tag in deken package names, and a filter in
the deken search plugin to show or hide test versions? Then Pd
community could more easily help with testing.

Katja

On Tue, Nov 29, 2016 at 10:09 AM, IOhannes m zmoelnig <zmoel...@iem.at> wrote:
> [:travis-ci propaganda:]
>
> On 2016-11-29 01:09, Dan Wilcox wrote:
>>> On Nov 29, 2016, at 12:46 AM, pd-list-requ...@lists.iem.at wrote:
>>>
>>> Obiously, I would like to set up a Mac build machine as well. What do I
>>> need to install on a clean system via command line?
>> Install the build system via:
>>
>> xcode-select —install
>
> just in case this is not obvious:
> travis-ci already features OSX builders, and being a continuous
> integration system, these builders already come with a compiler.
> so - in the case of travis-ci - there is no need to manually install xcode.
>
>> If you need libraries, I’d recommend using Homebrew: http://brew.sh
>
> i'd second that, but bear in mind that in this means that you will
> actually *build* the libraries (most of the times).
> in a CI (like travis-ci) this can lead to timeout problems: whenever a
> build is triggered, it starts from a pristine image. so all the
> dependencies need to be rebuilt, whenever a build of the main
> application(/library/external) is triggered.
> with a complex system (like Gem), i keep getting failed builds, because
> building the dependencies leaves little time to actually build Gem.
> however, you could download arbitrary (prebuilt) binaries, rather than
> build everything from scratch.
>
> fgmasr
> IOhannes
>
>
> ___
> 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] [delwrite~], or "what Pd operations are/should be realtime?"

[katja]

On Wed, Nov 23, 2016 at 11:22 AM, Roman Haefeli <reduz...@gmail.com> wrote:
> On Wed, 2016-11-23 at 10:48 +0100, IOhannes m zmoelnig wrote:
>> On 2016-11-22 17:29, Alexandre Torres Porres wrote:
>> >
>> > there is a clear method for the delay line in pd-l2ork,
>> > undocumented,
>> > but there, not sure how it is done,
>> implementing the "clear" is trivial.
>>
>> however, afaiu this is not the concern that miller has.
>> the concern is, that you are breaking some realtime assumptions
>> (deterministic, bound execution time), with *any* possible
>> implementation.
>
> This concern seems a bit arbitrary. Someone already brought up the
> 'const ' sent to array example, which is probably a similar
> operation and already exists. Also, I once found out that resizing
> arrays that are accessed by tilde objects causes a recalculation of the
> DSP graph and this leads to drop-outs, too (but might be only noticed
> when having a huge set of patches loaded so that the DSP graph is very
> big). Since I found out about this, I try to avoid resizing arrays
> altogether.
>
> Personally, I think a programming language shouldn't second-guess what
> is sensible for a programmer to do and what not. It should be up to the
> programmer whether they want to risk a drop-out or not.
>
> BTW, how can you implement a 'clear' method with abstractions?
>
> Roman
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
>

Not vanilla, but I use a sound-on-sound looper with [cyclone/poke~]
writing into the buffers and [tabread4~] reading.

If [delwrite~] would have a 'const' or 'clear' method I would use that
instead, if only because [cyclone/poke~] doesn't have a
subnormals-eliminator.

By the way I haven't noticed problems when flushing large buffers
(over 1 million samples total) in this looper while other audio is
still running.

Katja

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

Re: [PD] Results from PdCon round-table / workbench

[katja]

At http://www.nyu-waverlylabs.org/pdcon16/ there's currently one video
with these two subjects.

Starting at 00:00:30, conclusions from 'round workbench' sessions
about building Pd and libraries.

Starting at 00:47:00, round table discussion about the future of Pd.

Skip the first 30 seconds with 'intermission music', played while
technical problems were being solved.

Katja.



On Wed, Nov 23, 2016 at 11:48 AM, Roman Haefeli <reduz...@gmail.com> wrote:
> Hi all
>
> Greetings to all of you who had the pleasure to attend this year's Pd-
> Con.
>
> I'm interested to know about the outcomes of the following meetings:
>
>  * Workbench: building pd and libraries
>  * Open Roundtable on Future Pd Developments
>
> Are there any written/recorded remnants of those sessions?
>
> 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] OT : using libre office for data regression; WAS Re: efficient approximation of trig functions for hi pass formula (was: could vanilla borrow iemlib's hi pass filter recipe?)

[katja]

On Wed, Oct 19, 2016 at 6:32 PM, cyrille henry <c...@chnry.net> wrote:
>
>
> Le 19/10/2016 à 17:34, katja a écrit :
>>
>> Thanks for your update Cyrille. This seems a useful approach to find
>> approximations. I should really learn how to do that with libre
>> office. Do you have tutorial links? So far I found this:
>>
>> https://newtonexcelbach.wordpress.com/2015/06/28/using-linest-for-non-linear-curve-fitting-examples-hints-and-warnings/.
>
>
> I  learn to do this yesterday...
> Most informations I found on the web was outdated, but it's very simple.
> for short :
> create 2 column with X/Y data.
> select the data.
> click insert / diagram. select X/Y dispersion, in order to draw a X/Y graph
> of your data.
> then double click on the diagram and click on the curve to select it.
> then right click and "insert a tendency curve"
> then enjoy all option available.
> (there is no "odd only polynomial", but even value was almost 0 in the last
> example).
>
> Don't forget to click "draw the equation"
> The only problem is that i did not find a way to cut/paste the equation...
>
> (my libre office is in french, so menu translation may not be accurate)
>
>
>> For the filter recipe the curve must go through coordinates [0 1] and
>> [pi -1], to get the expected behavior when cutoff frequency is set to
>> DC or Nyquist. [hip~ 0] should not block DC, which is only possible
>> when the coefficient is exactly 1 like you get it with
>> (1-sin(0))/cos(0). I tuned my factors 'by hand' to do so. That may be
>> possible with your libre office result as well.
>
> yes, in my example the result is slightly different from 1 / -1.
> i tried again, adding about 20 points for X=0 and X=1 to get more weight for
> this coordinate.
> the coef where better, but not perfect.
>
> still it's a good starting point for manual adjustment.

That's what I thought, avoiding the initial guess iterations saves a
lot of time. Can you post your adjusted parameters? Being an
approximation the function will never be perfect. We can select the
best frequency response compromise.

>
>
> However, when done in
>>
>> double precision the calculation will give slightly different result.
>> Above or below 1, I don't know yet. In any case this has to be
>> considered when writing the C.
>
> shouldn’t it be clipped? (what is a filter with negative frequency, or
> frequency above Nyquist?)

Yes coefficients below -1 and above 1 must be clipped. But what if it
doesn't reach 1 at DC or -1 at Nyquist in double precision because of
the rounding difference. The behavior at those extremes would be
incorrect. Not that it matters now, we don't have double precision pd.
But code written today should be double-precision-proof, you never
know what will happen tomorrow.

>
> cheers
> c
>
>>
>> Katja
>>
>> On Wed, Oct 19, 2016 at 4:18 PM, cyrille henry <c...@chnry.net> wrote:
>>>
>>> since you manually adjust the coefficient, i wanted to see the difference
>>> with coefficient adjusted/optimised by a computer.
>>> I update the calc  using X from -0.5 to 0.5 with X = (x-0.5)*Pi
>>> The coefficient i get are really different from yours (when considering
>>> the
>>> Pi factor between them).
>>>
>>> I update you patch with this coefs.
>>> I don't understand why, but your coefs works better for low frequency.
>>> so, nothing better here, but I still think it's worth sharing, in case
>>> i'm
>>> not the only one wondering...
>>>
>>>
>>> also, there was a typo in my original mail, it's not a linear regression,
>>> but a polynomial regression (since the result was obviously polynomial)
>>>
>>> cheers
>>> c
>>>
>>>
>>> Le 19/10/2016 à 15:06, katja a écrit :
>>>>
>>>>
>>>> Changing the thread title to reflect the new approach. Extract of the
>>>> original thread;
>>>>
>>>> - I suggested using iemlib's hi pass filter recipe to improve
>>>> frequency response of [hip~]
>>>> - Christof Ressi pointed to formula in
>>>> http://www.arpchord.com/pdf/coeffs_first_order_filters_0p1.pdf
>>>> - this formula calculates feedback coefficient k = (1 - sin(a)) /
>>>> cos(a) where a = 2 * pi * fc / SR
>>>> - the filter implementation is y[n] = (x[n] - x[n-1]) * (1 + k) / 2
>>>> +   k * y[n-1]
>>>> - following convention in d_filter.c (and pd tilde classes in
>>>> general), trig functions should best be approximated
>>>> 

Re: [PD] efficient approximation of trig functions for hi pass formula (was: could vanilla borrow iemlib's hi pass filter recipe?)

[katja]

On Wed, Oct 19, 2016 at 4:25 PM, Jonathan Wilkes <jancs...@yahoo.com> wrote:
> When implemented in C, which approach takes the least amount of time
> to read, reason about, and fully comprehend?

That is an important question. Pd code is full of clever tricks and
bit hacks for dsp efficiency. What is the origin of q8_rsqrt(), why
and how does it work? What about PD_BIGORSMALL() in m_pd.h? And the
mysterious UNITBIT32 number in d_osc.c? Ideally such code should be
commented not only to denote its function (if necessary) but also to
reference the origin so you may be able to find info.

An approximation for a trig function should go in an (inline)
function, with a comment if the name can't clarify the function
sufficiently. But to fully comprehend is a different matter. Dsp code
in general takes substantial background to understand. You could
wonder why and how the approximation works, but the same question goes
for the function that it replaces.

Katja

>
> -Jonathan
>
>
>
>
> ____
> From: katja <katjavet...@gmail.com>
> To: "pd-list@lists.iem.at" <pd-list@lists.iem.at>
> Sent: Wednesday, October 19, 2016 9:06 AM
> Subject: [PD] efficient approximation of trig functions for hi pass formula
> (was: could vanilla borrow iemlib's hi pass filter recipe?)
>
> Changing the thread title to reflect the new approach. Extract of the
> original thread;
>
> - I suggested using iemlib's hi pass filter recipe to improve
> frequency response of [hip~]
> - Christof Ressi pointed to formula in
> http://www.arpchord.com/pdf/coeffs_first_order_filters_0p1.pdf
> - this formula calculates feedback coefficient k = (1 - sin(a)) /
> cos(a) where a = 2 * pi * fc / SR
> - the filter implementation is y[n] = (x[n] - x[n-1]) * (1 + k) / 2
> +  k * y[n-1]
> - following convention in d_filter.c (and pd tilde classes in
> general), trig functions should best be approximated
> - Cyrille provided libre office linear regression result for
> (1-sin(x))/cos(x)
>
> Thanks for the useful infos and discussion. My 'math coach' suggested
> using odd powers of -(x-pi/2) in an approximation polynomial for
> (1-sin(x))/cos(x). The best accuracy/performance balance I could get
> is with this 5th degree polynomial:
>
> (-(x-pi/2))*0.4908 - (x-pi/2)^3*0.04575 - (x-pi/2)^5*0.00541
>
> Using this approximation in the filter formula, response at cutoff
> frequency is -3 dB with +/-0.06 dB accuracy in the required range 0 <
> x < pi. It can be efficiently implemented in C, analogous to an
> approximation Miller uses in [bp~]. So that is what I'll try next.
>
> Attached patch hip~-models.pd illustrates and compares filter recipes
> using vanilla objects:
>
> - current implementation, most efficient, accuracy +/- 3 dB
> - implementation with trig functions, least efficient, accuracy +/- 0.01 dB
> - implementation with approximation for trig functions, efficient,
> accuracy +/- 0.06 dB
>
> A note on efficiency: coefficients in [hip~] are only recalculated
> when cutoff frequency is changed. How important is performance for a
> function rarely called? I'm much aware of the motto 'never optimize
> early', yet I spent much time on finding a fast approximation, for
> several reasons: it's a nice math challenge, instructive for cases
> where performance matters more, and I want to respect Miller's code
> efficiency when proposing a change. Today pd is even deployed on
> embedded devices so the frugal coding approach is still relevant.
> After 20 years.
>
> Katja
>
>
> On Tue, Oct 18, 2016 at 10:28 AM, cyrille henry <c...@chnry.net> wrote:
>>
>>
>> Le 18/10/2016 à 00:47, katja a écrit :
>>>
>>> The filter recipe that Christof pointed to was easy to plug into the C
>>> code of [hip~] and works perfectly. But when looking further in
>>> d_filter.c I came across an approximation function 'sigbp_qcos()' used
>>> in the bandpass filter. It made me realize once more how passionate
>>> Miller is about efficiency. I'm not going to make a fool of myself by
>>> submitting a 'fix' using two trig functions to calculate a filter
>>> coefficient when a simple approximation could do the job. So that is
>>> what I'm now looking into, with help of a math friend: an efficient
>>> polynomial approximation for (1-sin(x))/cos(x).
>>
>> according to libre office linear regression, for x between 0 and Pi,
>> (1-sin(x))/cos(x) is about :
>> -0.057255x³ + 0.27018x² - 0.9157x + 0.99344
>>
>> the calc is in attachment, if you want to tune the input source or
>> precision.
>> cheers
>> c
> ___
> 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] efficient approximation of trig functions for hi pass formula (was: could vanilla borrow iemlib's hi pass filter recipe?)

[katja]

Thanks for your update Cyrille. This seems a useful approach to find
approximations. I should really learn how to do that with libre
office. Do you have tutorial links? So far I found this:
https://newtonexcelbach.wordpress.com/2015/06/28/using-linest-for-non-linear-curve-fitting-examples-hints-and-warnings/.

For the filter recipe the curve must go through coordinates [0 1] and
[pi -1], to get the expected behavior when cutoff frequency is set to
DC or Nyquist. [hip~ 0] should not block DC, which is only possible
when the coefficient is exactly 1 like you get it with
(1-sin(0))/cos(0). I tuned my factors 'by hand' to do so. That may be
possible with your libre office result as well. However, when done in
double precision the calculation will give slightly different result.
Above or below 1, I don't know yet. In any case this has to be
considered when writing the C.

Katja

On Wed, Oct 19, 2016 at 4:18 PM, cyrille henry <c...@chnry.net> wrote:
> since you manually adjust the coefficient, i wanted to see the difference
> with coefficient adjusted/optimised by a computer.
> I update the calc  using X from -0.5 to 0.5 with X = (x-0.5)*Pi
> The coefficient i get are really different from yours (when considering the
> Pi factor between them).
>
> I update you patch with this coefs.
> I don't understand why, but your coefs works better for low frequency.
> so, nothing better here, but I still think it's worth sharing, in case i'm
> not the only one wondering...
>
>
> also, there was a typo in my original mail, it's not a linear regression,
> but a polynomial regression (since the result was obviously polynomial)
>
> cheers
> c
>
>
> Le 19/10/2016 à 15:06, katja a écrit :
>>
>> Changing the thread title to reflect the new approach. Extract of the
>> original thread;
>>
>> - I suggested using iemlib's hi pass filter recipe to improve
>> frequency response of [hip~]
>> - Christof Ressi pointed to formula in
>> http://www.arpchord.com/pdf/coeffs_first_order_filters_0p1.pdf
>> - this formula calculates feedback coefficient k = (1 - sin(a)) /
>> cos(a) where a = 2 * pi * fc / SR
>> - the filter implementation is y[n] = (x[n] - x[n-1]) * (1 + k) / 2
>> +   k * y[n-1]
>> - following convention in d_filter.c (and pd tilde classes in
>> general), trig functions should best be approximated
>> - Cyrille provided libre office linear regression result for
>> (1-sin(x))/cos(x)
>>
>> Thanks for the useful infos and discussion. My 'math coach' suggested
>> using odd powers of -(x-pi/2) in an approximation polynomial for
>> (1-sin(x))/cos(x). The best accuracy/performance balance I could get
>> is with this 5th degree polynomial:
>>
>> (-(x-pi/2))*0.4908 - (x-pi/2)^3*0.04575 - (x-pi/2)^5*0.00541
>>
>> Using this approximation in the filter formula, response at cutoff
>> frequency is -3 dB with +/-0.06 dB accuracy in the required range 0 <
>> x < pi. It can be efficiently implemented in C, analogous to an
>> approximation Miller uses in [bp~]. So that is what I'll try next.
>>
>> Attached patch hip~-models.pd illustrates and compares filter recipes
>> using vanilla objects:
>>
>> - current implementation, most efficient, accuracy +/- 3 dB
>> - implementation with trig functions, least efficient, accuracy +/- 0.01
>> dB
>> - implementation with approximation for trig functions, efficient,
>> accuracy +/- 0.06 dB
>>
>> A note on efficiency: coefficients in [hip~] are only recalculated
>> when cutoff frequency is changed. How important is performance for a
>> function rarely called? I'm much aware of the motto 'never optimize
>> early', yet I spent much time on finding a fast approximation, for
>> several reasons: it's a nice math challenge, instructive for cases
>> where performance matters more, and I want to respect Miller's code
>> efficiency when proposing a change. Today pd is even deployed on
>> embedded devices so the frugal coding approach is still relevant.
>> After 20 years.
>>
>> Katja
>>
>>
>> On Tue, Oct 18, 2016 at 10:28 AM, cyrille henry <c...@chnry.net> wrote:
>>>
>>>
>>>
>>> Le 18/10/2016 à 00:47, katja a écrit :
>>>>
>>>>
>>>> The filter recipe that Christof pointed to was easy to plug into the C
>>>> code of [hip~] and works perfectly. But when looking further in
>>>> d_filter.c I came across an approximation function 'sigbp_qcos()' used
>>>> in the bandpass filter. It made me realize once more how passionate
>>>> Miller is about efficiency. I'm not going to make a fool of myself by
>>>> submitting a

[PD] efficient approximation of trig functions for hi pass formula (was: could vanilla borrow iemlib's hi pass filter recipe?)

[katja]

Changing the thread title to reflect the new approach. Extract of the
original thread;

- I suggested using iemlib's hi pass filter recipe to improve
frequency response of [hip~]
- Christof Ressi pointed to formula in
http://www.arpchord.com/pdf/coeffs_first_order_filters_0p1.pdf
- this formula calculates feedback coefficient k = (1 - sin(a)) /
cos(a) where a = 2 * pi * fc / SR
- the filter implementation is y[n] = (x[n] - x[n-1]) * (1 + k) / 2
+   k * y[n-1]
- following convention in d_filter.c (and pd tilde classes in
general), trig functions should best be approximated
- Cyrille provided libre office linear regression result for (1-sin(x))/cos(x)

Thanks for the useful infos and discussion. My 'math coach' suggested
using odd powers of -(x-pi/2) in an approximation polynomial for
(1-sin(x))/cos(x). The best accuracy/performance balance I could get
is with this 5th degree polynomial:

(-(x-pi/2))*0.4908 - (x-pi/2)^3*0.04575 - (x-pi/2)^5*0.00541

Using this approximation in the filter formula, response at cutoff
frequency is -3 dB with +/-0.06 dB accuracy in the required range 0 <
x < pi. It can be efficiently implemented in C, analogous to an
approximation Miller uses in [bp~]. So that is what I'll try next.

Attached patch hip~-models.pd illustrates and compares filter recipes
using vanilla objects:

- current implementation, most efficient, accuracy +/- 3 dB
- implementation with trig functions, least efficient, accuracy +/- 0.01 dB
- implementation with approximation for trig functions, efficient,
accuracy +/- 0.06 dB

A note on efficiency: coefficients in [hip~] are only recalculated
when cutoff frequency is changed. How important is performance for a
function rarely called? I'm much aware of the motto 'never optimize
early', yet I spent much time on finding a fast approximation, for
several reasons: it's a nice math challenge, instructive for cases
where performance matters more, and I want to respect Miller's code
efficiency when proposing a change. Today pd is even deployed on
embedded devices so the frugal coding approach is still relevant.
After 20 years.

Katja


On Tue, Oct 18, 2016 at 10:28 AM, cyrille henry <c...@chnry.net> wrote:
>
>
> Le 18/10/2016 à 00:47, katja a écrit :
>>
>> The filter recipe that Christof pointed to was easy to plug into the C
>> code of [hip~] and works perfectly. But when looking further in
>> d_filter.c I came across an approximation function 'sigbp_qcos()' used
>> in the bandpass filter. It made me realize once more how passionate
>> Miller is about efficiency. I'm not going to make a fool of myself by
>> submitting a 'fix' using two trig functions to calculate a filter
>> coefficient when a simple approximation could do the job. So that is
>> what I'm now looking into, with help of a math friend: an efficient
>> polynomial approximation for (1-sin(x))/cos(x).
>
> according to libre office linear regression, for x between 0 and Pi,
> (1-sin(x))/cos(x) is about :
> -0.057255x³ + 0.27018x² - 0.9157x + 0.99344
>
> the calc is in attachment, if you want to tune the input source or
> precision.
> cheers
> c
#N canvas 56 116 600 483 10;
#X obj 142 161 osc~;
#X msg 501 129 \; pd dsp 1;
#X msg 501 176 \; pd dsp 0;
#X floatatom 142 98 8 0 0 0 - - -, f 8;
#X obj 142 260 env~ 8192;
#X floatatom 142 297 5 0 0 0 - - -, f 5;
#X text 171 161 test signal;
#X text 54 447 Katja Vetter Oct. 2016;
#X text 194 97 Hz;
#X obj 227 260 env~ 8192;
#X floatatom 227 301 5 0 0 0 - - -, f 5;
#X obj 227 331 -;
#X floatatom 227 365 5 0 0 0 - - -, f 5;
#X obj 145 45 hsl 200 15 0 22050 0 0 empty empty frequency(coarse)
20 8 0 10 -262144 -260097 -1 19900 0;
#X text 19 58 edge cases;
#X obj 57 257 env~ 8192;
#X floatatom 57 298 5 0 0 0 - - -, f 5;
#X obj 57 328 -;
#X floatatom 57 362 5 0 0 0 - - -, f 5;
#X obj 359 260 env~ 8192;
#X floatatom 359 301 5 0 0 0 - - -, f 5;
#X obj 359 331 -;
#X floatatom 359 365 5 0 0 0 - - -, f 5;
#X obj 145 16 hsl 200 15 0 1000 0 0 empty empty frequency(fine) 20
8 0 10 -262144 -260097 -1 9000 0;
#N canvas 110 156 413 534 hip1~ 0;
#X obj 40 25 inlet~;
#X obj 40 436 outlet~;
#X floatatom 122 414 8 0 0 0 - - -, f 8;
#X text 177 413 normalisation;
#X obj 40 405 *~ 0;
#X obj 40 345 rpole~;
#X obj 90 56 cnv 15 300 300 empty empty empty 20 12 0 14 -233017 -66577
0;
#X obj 306 126 atan;
#X msg 306 99 1;
#X obj 122 24 inlet;
#X floatatom 306 181 8 0 0 0 - - -, f 8;
#X obj 137 88 samplerate~;
#X obj 122 118 /;
#X obj 306 71 loadbang;
#X obj 122 169 *;
#X floatatom 155 119 8 0 0 0 - - -, f 8;
#X floatatom 152 186 8 0 0 0 - - -, f 8;
#X text 361 181 pi;
#X text 161 23 cut off frequency f(0);
#X obj 40 378 rzero~ 1;
#X obj 306 152 * 8;
#X obj 122 388 / 2;
#X text 204 185 a = 2*pi*fc/SR;
#X obj 122 361 + 1;
#X floatatom 154 330 8 0 0 0 - - -, f 8;
#X obj 122 258 t b f;
#X msg 122 283 1;
#X obj 122 313 -;
#X text 210 328 1-a;
#X text 36 474 Efficient [hip~] as implemented in v

Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

[katja]

The filter recipe that Christof pointed to was easy to plug into the C
code of [hip~] and works perfectly. But when looking further in
d_filter.c I came across an approximation function 'sigbp_qcos()' used
in the bandpass filter. It made me realize once more how passionate
Miller is about efficiency. I'm not going to make a fool of myself by
submitting a 'fix' using two trig functions to calculate a filter
coefficient when a simple approximation could do the job. So that is
what I'm now looking into, with help of a math friend: an efficient
polynomial approximation for (1-sin(x))/cos(x).

Katja

On Sat, Oct 15, 2016 at 4:59 PM, katja <katjavet...@gmail.com> wrote:
> Thanks for your pointers Christof. The recipe you mention from
> arpchord.com is different than iemlib's, but yields identical
> normalization and feedback coefficients, thus the same beautiful
> response. As you say, what's in the textbooks is common knowledge and
> can be used by everyone. Now I'll try to get the same result in C.
>
> By the way, [iemlib/hp~] seems to recalculate coefficients for every
> dsp vector which explains the higher CPU load.
>
> Katja
>
> On Sat, Oct 15, 2016 at 1:59 PM, Christof Ressi <christof.re...@gmx.at> wrote:
>>> If iemlib's license allows to use the recipe in BSD
>>
>> IMHO, the correct formular for the cutoff frequency below (which I guess is 
>> also used in [hp1~] since the frequency response is the same) is 'common 
>> knowledge', so I don't think you'd have to pay attention to any licence.
>>
>>
>>> Gesendet: Samstag, 15. Oktober 2016 um 13:52 Uhr
>>> Von: "Christof Ressi" <christof.re...@gmx.at>
>>> An: katja <katjavet...@gmail.com>, "Miller Puckette" <m...@ucsd.edu>
>>> Cc: pd-list <pd-l...@iem.at>
>>> Betreff: Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?
>>>
>>> > But coefficients aren't recalculated so
>>> > often, therefore this difference will be negligible.
>>>
>>> That's a good point. You're right that both involve a feedback and 
>>> feedforward, so I'm wondering why [hp1~] needs more CPU... otherwise, 
>>> iemlib's filters are very efficient.
>>>
>>> Anyway, I researched a bit and found the reason why the frequency response 
>>> of Pd filters seems 'wrong':
>>>
>>> Miller uses a formular for calculating the cutoff frequency which is taken 
>>> from analog filters but is not really adequate for digital filters since it 
>>> doesn't reflect the cyclic nature of the digital domain (although you can 
>>> see it in some articles on digital filters).
>>>
>>> Let's take [hip~] as an example:
>>>
>>> the formular for a 1-pole 1-zero highpass goes:
>>> y[n] = (x[n] - x[n-1]) * (1 + k) / 2   +   k * y[n-1]
>>>
>>> Miller calculates the position of the pole with
>>> k = 1 - (fc * 2*pi / SR).
>>>
>>> The correct formular, however (if you want the frequency response to be 
>>> zero at Nyquist!), would be
>>> k = (1-sin(a))/cos(a), where a = fc * 2*pi / SR.
>>>
>>> You can find it here: 
>>> http://www.arpchord.com/pdf/coeffs_first_order_filters_0p1.pdf
>>>
>>> BTW, the reason why [hip~] seems to get stuck at 7018 Hz is because Miller 
>>> clips the coefficient below 0, so it never reaches -1 (where the gain would 
>>> be all zero).
>>>
>>> Also, there is another approximation with a similiar behaviour, which goes 
>>> like this:
>>> k = e^(-2*pi*fc/SR). I could find it here: 
>>> http://www.dspguide.com/ch19/2.htm
>>> Here, the pole can only move from 1 to 0 and doesn't ever reach -1 as well.
>>>
>>> Now, is the behaviour of [hip~] 'wrong'?
>>> If you define at 1-pole 1-zero high pass filter as something which passes 
>>> everything at fc = DC and blocks everything at fc = Nyquist, then I'd say 
>>> yes.
>>> If it should roughly model an analogue filter (where the cutoff frequency 
>>> can go up to infinity) for low cutoff frequencies only, then I'd say no.
>>>
>>> Also, as I tried to point out, this issue with the cutoff frequency is true 
>>> for all Pd filters!
>>>
>>> So I think this behaviour should either be changed (great, if Katja is 
>>> willing to submit a patch!) or documented in the help patch (gain is not 0 
>>> at Nyquist!).
>>>
>>> I'm not an engineer or any expert on filter design. It's just my two cents 
>>> :-)
>>>
>>> Christof
>>>
>>>
>>&

Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

[katja]

Thanks for your pointers Christof. The recipe you mention from
arpchord.com is different than iemlib's, but yields identical
normalization and feedback coefficients, thus the same beautiful
response. As you say, what's in the textbooks is common knowledge and
can be used by everyone. Now I'll try to get the same result in C.

By the way, [iemlib/hp~] seems to recalculate coefficients for every
dsp vector which explains the higher CPU load.

Katja

On Sat, Oct 15, 2016 at 1:59 PM, Christof Ressi <christof.re...@gmx.at> wrote:
>> If iemlib's license allows to use the recipe in BSD
>
> IMHO, the correct formular for the cutoff frequency below (which I guess is 
> also used in [hp1~] since the frequency response is the same) is 'common 
> knowledge', so I don't think you'd have to pay attention to any licence.
>
>
>> Gesendet: Samstag, 15. Oktober 2016 um 13:52 Uhr
>> Von: "Christof Ressi" <christof.re...@gmx.at>
>> An: katja <katjavet...@gmail.com>, "Miller Puckette" <m...@ucsd.edu>
>> Cc: pd-list <pd-l...@iem.at>
>> Betreff: Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?
>>
>> > But coefficients aren't recalculated so
>> > often, therefore this difference will be negligible.
>>
>> That's a good point. You're right that both involve a feedback and 
>> feedforward, so I'm wondering why [hp1~] needs more CPU... otherwise, 
>> iemlib's filters are very efficient.
>>
>> Anyway, I researched a bit and found the reason why the frequency response 
>> of Pd filters seems 'wrong':
>>
>> Miller uses a formular for calculating the cutoff frequency which is taken 
>> from analog filters but is not really adequate for digital filters since it 
>> doesn't reflect the cyclic nature of the digital domain (although you can 
>> see it in some articles on digital filters).
>>
>> Let's take [hip~] as an example:
>>
>> the formular for a 1-pole 1-zero highpass goes:
>> y[n] = (x[n] - x[n-1]) * (1 + k) / 2   +   k * y[n-1]
>>
>> Miller calculates the position of the pole with
>> k = 1 - (fc * 2*pi / SR).
>>
>> The correct formular, however (if you want the frequency response to be zero 
>> at Nyquist!), would be
>> k = (1-sin(a))/cos(a), where a = fc * 2*pi / SR.
>>
>> You can find it here: 
>> http://www.arpchord.com/pdf/coeffs_first_order_filters_0p1.pdf
>>
>> BTW, the reason why [hip~] seems to get stuck at 7018 Hz is because Miller 
>> clips the coefficient below 0, so it never reaches -1 (where the gain would 
>> be all zero).
>>
>> Also, there is another approximation with a similiar behaviour, which goes 
>> like this:
>> k = e^(-2*pi*fc/SR). I could find it here: http://www.dspguide.com/ch19/2.htm
>> Here, the pole can only move from 1 to 0 and doesn't ever reach -1 as well.
>>
>> Now, is the behaviour of [hip~] 'wrong'?
>> If you define at 1-pole 1-zero high pass filter as something which passes 
>> everything at fc = DC and blocks everything at fc = Nyquist, then I'd say 
>> yes.
>> If it should roughly model an analogue filter (where the cutoff frequency 
>> can go up to infinity) for low cutoff frequencies only, then I'd say no.
>>
>> Also, as I tried to point out, this issue with the cutoff frequency is true 
>> for all Pd filters!
>>
>> So I think this behaviour should either be changed (great, if Katja is 
>> willing to submit a patch!) or documented in the help patch (gain is not 0 
>> at Nyquist!).
>>
>> I'm not an engineer or any expert on filter design. It's just my two cents 
>> :-)
>>
>> Christof
>>
>>
>>
>>
>>
>> > Gesendet: Samstag, 15. Oktober 2016 um 11:39 Uhr
>> > Von: katja <katjavet...@gmail.com>
>> > An: "Christof Ressi" <christof.re...@gmx.at>
>> > Cc: pd-list <pd-l...@iem.at>
>> > Betreff: Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?
>> >
>> > I'm pretty confident [hip~] would not loose its efficiency when using
>> > iemlib's recipe. Both hi pass filters have a feed forward and feedback
>> > component, with coefficients for normalization and feedback.
>> > Calculation of these coefficients is a bit more involved with iemlib's
>> > recipe, using trig functions. But coefficients aren't recalculated so
>> > often, therefore this difference will be negligible.
>> >
>> > To reassure, it is not my intention to spark another 'what's wrong
>> > with pd' thread. If iemlib's license allows to use the recipe in BSD
>> > code

Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?

[katja]

I'm pretty confident [hip~] would not loose its efficiency when using
iemlib's recipe. Both hi pass filters have a feed forward and feedback
component, with coefficients for normalization and feedback.
Calculation of these coefficients is a bit more involved with iemlib's
recipe, using trig functions. But coefficients aren't recalculated so
often, therefore this difference will be negligible.

To reassure, it is not my intention to spark another 'what's wrong
with pd' thread. If iemlib's license allows to use the recipe in BSD
code I'll try patch the C of [hip~] and submit on the tracker for
review. Who knows, it may be a no-brainer.

Katja





On Sat, Oct 15, 2016 at 2:34 AM, Christof Ressi <christof.re...@gmx.at> wrote:
> There are a number of big problems with all build-in filters in Pd (expect 
> for the raw filters).
>
> Problem number 1:
> [lop~] and [hip~] both use a weird (you could also say: wrong) formula for 
> the cutoff frequency which makes them gradually converge to a fixed output 
> state (reached by about 7000 Hz). The same is true for [vcf~] and [bp~] with 
> Q <= 1. Therefore the actual cutoff frequency is only correct for very low 
> frequencies and approximately gets more and more off until it doesn't move at 
> all.
>
> Problem number 2:
> [bp~] and [vcf~] don't have zeros at DC and Nyquist. For low Q values, the 
> slope is different for each side and changes with frequency.
>
> Problem number 3:
> the gain at the center frequency is not 1 for both [bp~] and [vcf~]. It 
> rather depends on frequency and Q. [bp~] even has has a gain of 2 for Q <= 1!
>
> I did some FFT plots, see the attachment.
>
> I remember Miller saying somewhere that these filters are not designed for 
> high cutoff frequencies - but even for low frequencies, the behaviour of 
> [bp~] and [vcf~] is horrible. I can see these filters are mere approximations 
> to reduce CPU usage.
> [hip~] is indeed much more efficient than iemlib's [hp1~], so it's well 
> suited for DC removal (but not much else).
> [bp~] only is a little bit more CPU friendly than iemlib's [bp2~] - but the 
> latter one has a correct and stable frequency response.
> [vcf~], however, is a real CPU sucker!!! 100 [vcf~] objects need 3,40% on my 
> laptop whereas 100 of iemlib's [vcf_bp2~] only need 1,80%! But you have to 
> consider that [vcf_bp2~] not only acts correctly but lets you set the Q at 
> audio rate. The high CPU usage of [vcf~] seems like a bug to me...
>
> I only use the vanilla filters for the most basic stuff like DC removal and 
> smoothing. I guess these are the use cases which Miller had in mind and that 
> way [lop~] and [hip~] have their justification (although there should be some 
> more warning about the 'wrong' frequency response in the help file).
> But [bp~] and [vcf~] are almost unusable IMHO and should probably be replaced 
> by better filters in the future (while keeping the old ones for compatibility 
> reasons).
>
> Christof
>
>
>> Gesendet: Freitag, 14. Oktober 2016 um 23:51 Uhr
>> Von: katja <katjavet...@gmail.com>
>> An: pd-list <pd-l...@iem.at>
>> Betreff: [PD] could vanilla borrow iemlib's hi pass filter recipe?
>>
>> In pd 0.47.1 [hip~] is still not perfect. Attenuation at cutoff is not
>> constant over the frequency range: -6 dB with cutoff=SR/8, -3 dB with
>> cutoff=SR/4, 0 DB with cutoff=SR/2. In contrast, iemlib's [hp1~] has
>> -3 dB at cutoff consistently.
>>
>> Could vanilla pd implement iemlib's hipass filter recipe? I don't know
>> if the license also covers the math. Documentation in
>> https://git.iem.at/pd/iemlib/tree/master points to external literature
>> for part of the math (bilinear transform). I've implemented the recipe
>> with vanilla objects for comparison, see attached.
>>
>> Katja
>> ___
>> 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] could vanilla borrow iemlib's hi pass filter recipe?

[katja]

In pd 0.47.1 [hip~] is still not perfect. Attenuation at cutoff is not
constant over the frequency range: -6 dB with cutoff=SR/8, -3 dB with
cutoff=SR/4, 0 DB with cutoff=SR/2. In contrast, iemlib's [hp1~] has
-3 dB at cutoff consistently.

Could vanilla pd implement iemlib's hipass filter recipe? I don't know
if the license also covers the math. Documentation in
https://git.iem.at/pd/iemlib/tree/master points to external literature
for part of the math (bilinear transform). I've implemented the recipe
with vanilla objects for comparison, see attached.

Katja
#N canvas 432 238 483 402 10;
#X obj 47 130 hip~;
#X obj 48 164 env~ 8192;
#X obj 46 83 osc~;
#X obj 90 21 hsl 200 15 0 22000 0 0 empty empty frequency 20 8 0 10
-262144 -260097 -1 100 1;
#X floatatom 48 201 5 0 0 0 - - -, f 5;
#X msg 389 21 \; pd dsp 1;
#X msg 390 69 \; pd dsp 0;
#X obj 212 165 env~ 8192;
#X floatatom 212 203 5 0 0 0 - - -, f 5;
#X floatatom 87 57 8 0 0 0 - - -, f 8;
#X text 79 130 vanilla built in;
#N canvas 38 147 451 560 hip~ 0;
#X obj 40 25 inlet~;
#X obj 41 468 outlet~;
#X floatatom 225 448 8 0 0 0 - - -, f 8;
#X floatatom 122 401 8 0 0 0 - - -, f 8;
#X text 120 418 normalisation;
#X obj 225 361 - 1;
#X obj 252 361 + 1;
#X obj 225 334 t f f;
#X obj 225 425 /;
#X obj 149 358 + 1;
#X obj 122 334 t f f;
#X obj 122 375 /;
#X obj 41 392 *~ 0;
#X obj 41 442 rpole~;
#X obj 100 13 cnv 15 300 300 empty empty empty 20 12 0 14 -233017 -66577
0;
#X obj 122 222 cos;
#X obj 122 194 t f f;
#X obj 149 222 sin;
#X obj 122 251 /;
#X floatatom 166 268 8 0 0 0 - - -, f 8;
#X obj 306 113 atan;
#X msg 306 86 1;
#X obj 122 26 inlet;
#X floatatom 306 168 8 0 0 0 - - -, f 8;
#X obj 137 65 samplerate~;
#X obj 122 95 /;
#X obj 306 48 loadbang;
#X obj 306 139 * 4;
#X obj 122 156 *;
#X floatatom 155 96 8 0 0 0 - - -, f 8;
#X floatatom 165 173 8 0 0 0 - - -, f 8;
#X text 223 269 cot(pi*f(0)/SR);
#X text 222 172 pi*f(0)/SR;
#X text 361 168 pi;
#X text 161 26 cut off frequency f(0);
#X text 226 468 feedback coefficient;
#X obj 41 352 rzero~ 1;
#X text 39 502 filter recipe of [iemlib/hp1~] \, see documentation
by Thomas Musil: https://git.iem.at/pd/iemlib/tree/master;
#X connect 0 0 36 0;
#X connect 5 0 8 0;
#X connect 6 0 8 1;
#X connect 7 0 5 0;
#X connect 7 1 6 0;
#X connect 8 0 2 0;
#X connect 8 0 13 1;
#X connect 9 0 11 1;
#X connect 10 0 11 0;
#X connect 10 1 9 0;
#X connect 11 0 3 0;
#X connect 11 0 12 1;
#X connect 12 0 13 0;
#X connect 13 0 1 0;
#X connect 15 0 18 0;
#X connect 16 0 15 0;
#X connect 16 1 17 0;
#X connect 17 0 18 1;
#X connect 18 0 19 0;
#X connect 18 0 10 0;
#X connect 18 0 7 0;
#X connect 20 0 27 0;
#X connect 21 0 20 0;
#X connect 22 0 25 0;
#X connect 24 0 25 1;
#X connect 24 0 29 0;
#X connect 25 0 28 0;
#X connect 26 0 24 0;
#X connect 26 0 21 0;
#X connect 27 0 23 0;
#X connect 27 0 28 1;
#X connect 28 0 30 0;
#X connect 28 0 16 0;
#X connect 36 0 12 0;
#X restore 212 129 pd hip~;
#X obj 130 165 env~ 8192;
#X floatatom 130 202 5 0 0 0 - - -, f 5;
#X obj 48 232 -;
#X floatatom 48 267 5 0 0 0 - - -, f 5;
#X obj 212 233 -;
#X floatatom 212 267 5 0 0 0 - - -, f 5;
#X text 88 269 dB;
#X text 249 267 dB;
#X text 75 83 test signal;
#X text 46 350 Katja Vetter Oct. 2016;
#X text 262 129 recipe from iemlib;
#X text 138 58 Hz;
#X text 45 309 Test hipass filter attenuation at cutoff frequency.
Output should be -3dB at cutoff over the entire frequency range.;
#X connect 0 0 1 0;
#X connect 1 0 4 0;
#X connect 2 0 0 0;
#X connect 2 0 11 0;
#X connect 2 0 12 0;
#X connect 3 0 9 0;
#X connect 4 0 14 0;
#X connect 7 0 8 0;
#X connect 8 0 16 0;
#X connect 9 0 2 0;
#X connect 9 0 0 1;
#X connect 9 0 11 1;
#X connect 11 0 7 0;
#X connect 12 0 13 0;
#X connect 13 0 14 1;
#X connect 13 0 16 1;
#X connect 14 0 15 0;
#X connect 16 0 17 0;
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Proposing a cyclone update / another Pre Alpha release (milestone 2)

[katja]

Compiling cyclone03prealpha4 on Linux succeeds but installing fails
because data files are not found on locations defined in the lib
makefile. Details on:

https://github.com/porres/pd-cyclone/issues/134

Weird issue with [comment] happens on Linux too. Initially the help
patch titles seemed to be just off position, later they disappeared
altogether.

I'm happy to see that help patches retained their compact appearance
even when some classes have received extensive additional
documentation. Also I like how compatibility issues are meticulously
documented in the help patches.

This is just my first impression. I'm not saying there's no issues
other than the above mentioned, but I didn't look deeper.

Katja

On Wed, Oct 5, 2016 at 2:52 AM, Matt Barber <brbrof...@gmail.com> wrote:
> Yikes. I'll take a look at [comment] fonts tonight.
>
> On Tue, Oct 4, 2016 at 7:27 PM, Alexandre Torres Porres <por...@gmail.com>
> wrote:
>>
>> 2016-10-04 20:15 GMT-03:00 Christof Ressi <christof.re...@gmx.at>:
>>>
>>> Hi Alex,
>>>
>>> just wanted to tell you that I could successfully and easily build your
>>> cyclone release on my windows machine (Levono Thinkpad, Windows 7). Good
>>> work! If you need binaries (now or later), let me know.
>>
>>
>> great, i'd love some now to give to my students :)
>>
>>
>>>
>>>  One suggestion: make sure to write [cyclone/comment]
>>
>>
>> good call, i had that in mind, but now i put it in my list...
>>
>>>
>>> I don't know how they are supposed to look but they seem a bit off on
>>> Windows. My it has something to do with the font (size)? See attachement.
>>
>>
>> yeah they look bad :/ not sure if font size, cause if I change it here, I
>> get something else... it shoudn;t really screw with the [comment] font size
>> (that I use for the object name)
>>
>> see my attachment
>>
>> 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
>

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

Re: [PD] Proposing a cyclone update / another Pre Alpha release (milestone 2)

[katja]

The include path topic is relevant for pd libs in general. Instead of
workarounds or downstream fixes let's try to find an approach that is
useful for everyone. I've opened this issue:

https://github.com/pure-data/pd-lib-builder/issues/25

Katja

On Mon, Oct 3, 2016 at 10:44 PM, Alexandre Torres Porres
<por...@gmail.com> wrote:
>
>> Or I uninstall “extended”?
>
>
>
> What I did as a quick solution was replacing the one in extended with the
> one in the new vanilla, but we'll work it out in the makefile and in the
> project for the future ;)
>
> 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] Proposing a cyclone update / another Pre Alpha release (milestone 2)

[katja]

Value of 'pdincludepath' should be the full path of directory
containing pd API files. The standard pd includes path is different
per platform, and per pd flavor. When in doubt just locate your
preferred m_pd.h and take the full path of directory where it sits.

On Tue, Oct 4, 2016 at 12:35 AM, Lucas Cordiviola  wrote:
> Using pdincludepath:
>
> 
>
> make pdincludepath=C:/Users/Lucarda/Downloads/pd 2> log.txt
>
>
>
> ls: C:/Users/Lucarda/Downloads/pd/m_pd.h: No such file or directory
> pd-lib-
>
> builder/Makefile.pdlibbuilder:690: Where is Pd API m_pd.h? Do 'make help'
> for info.
> binaries_src/control/mean.c:5:18: fatal error: m_pd.h: No such file or
> directory
>
> compilation terminated.
>
> make: *** [binaries_src/control/mean.o] Error 1
>
>
> ---
>
>
>
> make pdincludepath=C:/Users/Lucarda/Downloads/pd/src 2> log.txt
>
>
>
> OK,
>
> See attached log.txt
>
>
>
> Do you feel is better to delete extended?
>
>
>
> Mensaje telepatico asistido por maquinas.
>
>
> 
> From: Alexandre Torres Porres 
> Sent: Monday, October 3, 2016 10:09 PM
> To: Lucas Cordiviola
> Cc: pd-list@lists.iem.at
> Subject: Re: [PD] Proposing a cyclone update / another Pre Alpha release
> (milestone 2)
>
>
>> Feel free to ask me to uninstall “extended” and see what happens (also for
>> the experiment), I`m not using it anymore and I have a ZIP version around.
>
>
>
> that'd be the easiest, but you can try replacing them all or using the
> argument, thanks
>
> ___
> 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] Proposing a cyclone update / another Pre Alpha release (milestone 2)

[katja]

There's two better things you can do than editing Makefile.pdlibbuilder:

1. build with make argument 'pdincludepath='

2. open an issue on https://github.com/pure-data/pd-lib-builder to
discuss the search order

Makefile.pdlibbuilder is a community-maintained versioned helper
makefile. It is impractical to maintain personalized versions of it.

Katja

On Mon, Oct 3, 2016 at 9:52 PM, Matt Barber <brbrof...@gmail.com> wrote:
> A lot of them just drop the relevant m_pd.h into the project itself, which
> is certainly doable.
>
> On Mon, Oct 3, 2016 at 3:47 PM, Alexandre Torres Porres <por...@gmail.com>
> wrote:
>>
>> i mean, fix in the makefile, apparently there's a way to specify a
>> subfolder with the pd source into our project
>>
>> 2016-10-03 16:45 GMT-03:00 Alexandre Torres Porres <por...@gmail.com>:
>>>
>>> yeah, we gotta fix that in pd-lib-builder ourselves, and provide the pd
>>> source from vanilla for it to check in a subfolder, that's the safest thing
>>> to do, so lets jump to that ;)
>>>
>>> thanks
>>>
>>> 2016-10-03 16:26 GMT-03:00 Matt Barber <brbrof...@gmail.com>:
>>>>
>>>> Thanks, Lucas. There are some useful things here, and I see a few things
>>>> to fix, especially with implicit casting.
>>>>
>>>> One thing that's confusing in compiling is which m_pd.h to use. It looks
>>>> like your pd-lib-builder found m_pd.h from Pd extended, which may break
>>>> things in cases where we're using the updated one from newer vanillas. If
>>>> you have vanilla installed, there's a way to fix it by changing the code in
>>>> pd-lib-builder/Makefile.pdlibbuilder, lines 562-567:
>>>> Here's the current:
>>>>
>>>>   ifndef pdincludepath
>>>> pdincludepath := $(shell ls -d
>>>> "$(PROGRAMFILES)/pd/include/pdextended")
>>>>   endif
>>>>   ifndef pdincludepath
>>>> pdincludepath := $(shell ls -d "$(PROGRAMFILES)/pd/src")
>>>>   endif
>>>>
>>>> I think you can just comment out the first three lines, or move them
>>>> below the next three.
>>>>
>>>> Much appreciated.
>>>>
>>>> Matt
>>>>
>>>> On Mon, Oct 3, 2016 at 2:45 PM, Lucas Cordiviola <lucard...@hotmail.com>
>>>> wrote:
>>>>>
>>>>> Hi Alexandre,
>>>>>
>>>>> >For instance, I only compiled for mac, maybe somebody else can help us
>>>>> > >compiling for windows?
>>>>>
>>>>>
>>>>>
>>>>> This is the first time I`ve compiled something. Almost all objects were
>>>>> created. I used Mingw.
>>>>>
>>>>> Report attached:
>>>>> “Cyclone-0.3.pre.alpha-milestone2-mingw32-report-1.txt”
>>>>>
>>>>> Tomorrow I will test objects, which ones I have to avoid?
>>>>>
>>>>> Salutti,
>>>>> Lucarda.
>>>>>
>>>>>
>>>>> Mensaje telepatico asistido por maquinas.
>>>>>
>>>>>
>>>>> 
>>>>> From: Pd-list <pd-list-boun...@lists.iem.at> on behalf of Alexandre
>>>>> Torres Porres <por...@gmail.com>
>>>>> Sent: Monday, October 3, 2016 6:00 AM
>>>>> To: pd-list@lists.iem.at
>>>>> Subject: [PD] Proposing a cyclone update / another Pre Alpha release
>>>>> (milestone 2)
>>>>>
>>>>>
>>>>> Howdy, as some of you know, me Derek and Matt have been working on new
>>>>> updates for cyclone. .
>>>>>
>>>>>
>>>>> ___
>>>>> 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] [bob~] denormals issue?

[katja]

On Linux i386 bob~ produces subnormals as well and very high cpu load.
It is not the slowly decaying signal that other filters tend to give,
but a quick decay to a fixed small number.

It's weird indeed when subnormals cause different CPU load depending
on how they are compiled. Since MinGW is a gcc port I would think it
uses the same math implementation which produces such high CPU load
for bob~ subnormals on my system.

On Thu, Sep 22, 2016 at 12:01 AM, Christof Ressi <christof.re...@gmx.at> wrote:
> I tried your patch with the [bob~] object shipped with the Windows binaries. 
> I clearly get subnormals! It's actually no wonder because there isn't any 
> protection against subnormals in the code (at least I couldn't spot it).
> But the weird thing is: the [bob~] I compiled myself would also show 
> subnormals in your patch but the CPU load is not affected...
>
>> Gesendet: Mittwoch, 21. September 2016 um 23:47 Uhr
>> Von: katja <katjavet...@gmail.com>
>> An: "Christof Ressi" <christof.re...@gmx.at>
>> Cc: "pd-list@lists.iem.at" <pd-list@lists.iem.at>
>> Betreff: Re: Re: Re: [PD] [bob~] denormals issue?
>>
>> Without -O flags you get debug-level and all function inlining is
>> disabled, depending on the code it can make a huge difference indeed.
>> But Pd is probably compiled with at least -O2. So the flags don't make
>> much difference. The compiler? Doesn't Miller compile with MinGW
>> nowadays, I don't know. MinGW brings its own standard C libs, which
>> may implement math functions differently than MS. But regarding
>> denormals I guess they both respect the IEEE 754 standard.
>>
>> You can check if you really have subnormals using attached patch
>> denorm-test.pd you. The patch tests lop~, change it to bob~.
>>
>> On Wed, Sep 21, 2016 at 11:18 PM, Christof Ressi <christof.re...@gmx.at> 
>> wrote:
>> > the SSE optimizations don't seem to matter at all. skipping -ffast-math 
>> > gives a slight overall CPU rise, while skipping -O3 gives me huge CPU rise 
>> > (20 bob~ filters are already to much for one core). Even when skipping all 
>> > of those flags, the denormals issue is still not present.
>> >
>> > Maybe it has something to do with the compiler?
>> >
>> >> Gesendet: Mittwoch, 21. September 2016 um 22:47 Uhr
>> >> Von: katja <katjavet...@gmail.com>
>> >> An: "Christof Ressi" <christof.re...@gmx.at>, "pd-list@lists.iem.at" 
>> >> <pd-list@lists.iem.at>
>> >> Betreff: Re: Re: [PD] [bob~] denormals issue?
>> >>
>> >> I'm curious to know if the flags do flush denormals on your processor.
>> >> Forgot to mention that '-O3 -ffast-math' are also set,
>> >> platform-independent. So if you have a chance to try which flag does
>> >> something... It's just curiosity.
>> >>
>> >> On Wed, Sep 21, 2016 at 10:34 PM, Christof Ressi <christof.re...@gmx.at> 
>> >> wrote:
>> >> > Hi Katja,
>> >> >
>> >> >> Even if your test reveals a beneficial effect from compiler flags,
>> >> >> it is better when denormals are detected and flushed in the C code.
>> >> >
>> >> > definitely! Maybe using the PD_BIGORSMALL macro on each filter state at 
>> >> > the end of the DSP routine does the trick, just like in all the other 
>> >> > recursive filters in Pd.
>> >> >
>> >> >
>> >> >
>> >> >> Von: katja <katjavet...@gmail.com>
>> >> >> An: "Christof Ressi" <christof.re...@gmx.at>
>> >> >> Cc: pd-list <pd-l...@iem.at>, "Miller Puckette" <m...@ucsd.edu>
>> >> >> Betreff: Re: [PD] [bob~] denormals issue?
>> >> >>
>> >> >> Hi Christof,
>> >> >>
>> >> >> Makefile.pdlibbuilder passes flags '-march=pentium4 -msse -msse2
>> >> >> -mfpmath=sse' for optimization to the compiler on Windows. You could
>> >> >> try compiling without (some of) these flags to see if they are
>> >> >> responsible for the different behavior. Makefile-defined optimization
>> >> >> flags can be overriden with argument CFLAGS given on command line.
>> >> >>
>> >> >> The effect of optimization flags on denormals varies per processor
>> >> >> type, unfortunately. When we had denormals on Raspberry Pi ARMv6 they
>> >> &

Re: [PD] [bob~] denormals issue?

[katja]

Without -O flags you get debug-level and all function inlining is
disabled, depending on the code it can make a huge difference indeed.
But Pd is probably compiled with at least -O2. So the flags don't make
much difference. The compiler? Doesn't Miller compile with MinGW
nowadays, I don't know. MinGW brings its own standard C libs, which
may implement math functions differently than MS. But regarding
denormals I guess they both respect the IEEE 754 standard.

You can check if you really have subnormals using attached patch
denorm-test.pd you. The patch tests lop~, change it to bob~.

On Wed, Sep 21, 2016 at 11:18 PM, Christof Ressi <christof.re...@gmx.at> wrote:
> the SSE optimizations don't seem to matter at all. skipping -ffast-math gives 
> a slight overall CPU rise, while skipping -O3 gives me huge CPU rise (20 bob~ 
> filters are already to much for one core). Even when skipping all of those 
> flags, the denormals issue is still not present.
>
> Maybe it has something to do with the compiler?
>
>> Gesendet: Mittwoch, 21. September 2016 um 22:47 Uhr
>> Von: katja <katjavet...@gmail.com>
>> An: "Christof Ressi" <christof.re...@gmx.at>, "pd-list@lists.iem.at" 
>> <pd-list@lists.iem.at>
>> Betreff: Re: Re: [PD] [bob~] denormals issue?
>>
>> I'm curious to know if the flags do flush denormals on your processor.
>> Forgot to mention that '-O3 -ffast-math' are also set,
>> platform-independent. So if you have a chance to try which flag does
>> something... It's just curiosity.
>>
>> On Wed, Sep 21, 2016 at 10:34 PM, Christof Ressi <christof.re...@gmx.at> 
>> wrote:
>> > Hi Katja,
>> >
>> >> Even if your test reveals a beneficial effect from compiler flags,
>> >> it is better when denormals are detected and flushed in the C code.
>> >
>> > definitely! Maybe using the PD_BIGORSMALL macro on each filter state at 
>> > the end of the DSP routine does the trick, just like in all the other 
>> > recursive filters in Pd.
>> >
>> >
>> >
>> >> Von: katja <katjavet...@gmail.com>
>> >> An: "Christof Ressi" <christof.re...@gmx.at>
>> >> Cc: pd-list <pd-l...@iem.at>, "Miller Puckette" <m...@ucsd.edu>
>> >> Betreff: Re: [PD] [bob~] denormals issue?
>> >>
>> >> Hi Christof,
>> >>
>> >> Makefile.pdlibbuilder passes flags '-march=pentium4 -msse -msse2
>> >> -mfpmath=sse' for optimization to the compiler on Windows. You could
>> >> try compiling without (some of) these flags to see if they are
>> >> responsible for the different behavior. Makefile-defined optimization
>> >> flags can be overriden with argument CFLAGS given on command line.
>> >>
>> >> The effect of optimization flags on denormals varies per processor
>> >> type, unfortunately. When we had denormals on Raspberry Pi ARMv6 they
>> >> wouldn't go away no matter what flags, is what I remember. Even if
>> >> your test reveals a beneficial effect from compiler flags, it is
>> >> better when denormals are detected and flushed in the C code. Anyway,
>> >> it is still interesting to know what makes the difference.
>> >>
>> >> Katja
>> >>
>> >> On Wed, Sep 21, 2016 at 12:32 AM, Christof Ressi <christof.re...@gmx.at> 
>> >> wrote:
>> >> > Hmmm... I compiled [bob~] myself with MinGW and pd-lib-builder and I 
>> >> > noticed two things:
>> >> > 1) the CPU rise is gone
>> >> > 2) it needs only half the CPU. I put 20 [bob~] objects in a switched 
>> >> > subpatch and measured the CPU load. The DLL which comes with the 
>> >> > Windows binaries needs 15%, while my own DLL needs only 7%! That's 
>> >> > quite a deal...
>> >> >
>> >> > Christof
>> >> >
>> >> > PS: I attached the DLL in case you wanna try it yourself.
>> >> >
>> >> >
>> >> >> Gesendet: Samstag, 17. September 2016 um 22:58 Uhr
>> >> >> Von: "Christof Ressi" <christof.re...@gmx.at>
>> >> >> An: pd-l...@iem.at, "Miller Puckette" <m...@ucsd.edu>
>> >> >> Betreff: [PD] [bob~] denormals issue?
>> >> >>
>> >> >> Hi Miller,
>> >> >>
>> >> >> feeding audio into [bob~] and then going to zero will increase the CPU 
>> >> >> load by ca. 6%. Clearing the filte

Re: [PD] [bob~] denormals issue?

[katja]

Hi Christof,

Makefile.pdlibbuilder passes flags '-march=pentium4 -msse -msse2
-mfpmath=sse' for optimization to the compiler on Windows. You could
try compiling without (some of) these flags to see if they are
responsible for the different behavior. Makefile-defined optimization
flags can be overriden with argument CFLAGS given on command line.

The effect of optimization flags on denormals varies per processor
type, unfortunately. When we had denormals on Raspberry Pi ARMv6 they
wouldn't go away no matter what flags, is what I remember. Even if
your test reveals a beneficial effect from compiler flags, it is
better when denormals are detected and flushed in the C code. Anyway,
it is still interesting to know what makes the difference.

Katja

On Wed, Sep 21, 2016 at 12:32 AM, Christof Ressi <christof.re...@gmx.at> wrote:
> Hmmm... I compiled [bob~] myself with MinGW and pd-lib-builder and I noticed 
> two things:
> 1) the CPU rise is gone
> 2) it needs only half the CPU. I put 20 [bob~] objects in a switched subpatch 
> and measured the CPU load. The DLL which comes with the Windows binaries 
> needs 15%, while my own DLL needs only 7%! That's quite a deal...
>
> Christof
>
> PS: I attached the DLL in case you wanna try it yourself.
>
>
>> Gesendet: Samstag, 17. September 2016 um 22:58 Uhr
>> Von: "Christof Ressi" <christof.re...@gmx.at>
>> An: pd-l...@iem.at, "Miller Puckette" <m...@ucsd.edu>
>> Betreff: [PD] [bob~] denormals issue?
>>
>> Hi Miller,
>>
>> feeding audio into [bob~] and then going to zero will increase the CPU load 
>> by ca. 6%. Clearing the filter or adding a tiny amount of noise brings the 
>> CPU load back to its usual level immediately, so I guess it's a problem with 
>> denormals.
>> My Pd load meter won't really show the increase, but it's clearly visibly on 
>> Process Explorer.
>>
>> See my attached patch. Tried with Pd 0.47.1, Lenovo Thinkpad L440, Windows 7.
>>
>> Christof___
>> 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] A 6th order hilbert transformer?

[katja]

The phase shift test from my previous mail expresses quadrature
transformer output as normalized instantaneous frequencies (cycles).
Depending on frequency (within the working range), deviation can be up
to 1/100 of a cycle both for [olli~] and Pd's [hilbert~]. Of those
two, [hilbert~] may even be most accurate, but [olli~]'s working range
extends two octaves lower.

The question is what accuracy and range you need per application, and
how audible deviations are in practice. Would be nice to have a
catalog of quadrature transformers (in Pd abstraction) for testing and
prototyping, including Csound's.

Katja

On Fri, Jun 24, 2016 at 3:47 AM, Alexandre Torres Porres
<por...@gmail.com> wrote:
> I guess I have to find a way to implement it and test it.
>
> By the way, I'm testing max's hilbert~ with olli's - find picture attached.
>
> is this a good way to test it by the way? Seems Max's is more accurate
>
>
>
> 2016-06-23 22:40 GMT-03:00 Matt Barber <brbrof...@gmail.com>:
>>
>> Not sure. I've used csound's a lot in ambisonic decoding and it's always
>> worked well.
>>
>> On Thu, Jun 23, 2016 at 6:06 PM, Alexandre Torres Porres
>> <por...@gmail.com> wrote:
>>>
>>> olli's seems easier for me to code, and better than csound's huh?
>>>
>>> thanks
>>>
>>> 2016-06-23 11:27 GMT-03:00 Matt Barber <brbrof...@gmail.com>:
>>>>
>>>> csound's hilbert transform is also 6th-order. Code here:
>>>>
>>>>
>>>> https://github.com/csound/csound/blob/2ec0073f4bb55253018689a19dd88a432ea6da46/Opcodes/ugsc.c
>>>>
>>>> On Thu, Jun 23, 2016 at 9:16 AM, katja <katjavet...@gmail.com> wrote:
>>>>>
>>>>> Attached is a zip with test patch for [olli~] and [hilbert~] so you
>>>>> can compare and also check with different sample rates. It seems that
>>>>> Olli's coefficients are optimized to work well from 20 Hz up at 44K1
>>>>> sample rate, and Pd's built-in from 80 Hz up. They both work at other
>>>>> samples rates too, but with different range.
>>>>>
>>>>> Since the coefficients for x[n-2] and y[n-2] are non-zero in the
>>>>> biquads, the maximum phase shift  is as large as in any 2nd order
>>>>> section, therefore I think the four sections together are 8 order
>>>>> equivalent indeed.
>>>>>
>>>>> By the way, the abstraction in my first response wasn't completely
>>>>> vanilla-compatible, this is fixed in current attachment (for anyone
>>>>> else interested).
>>>>>
>>>>> Katja
>>>>>
>>>>> On Thu, Jun 23, 2016 at 6:24 AM, Alexandre Torres Porres
>>>>> <por...@gmail.com> wrote:
>>>>> > Awesome, I can code it based on that :) but which order is it?
>>>>> >
>>>>> > I see it has 4 biquads, but it doesnt look like an 8th order because
>>>>> > some
>>>>> > coefficients are zeroed out, so I'm confused.
>>>>> >
>>>>> > Another question, does it work at any sample rate? This question is
>>>>> > also
>>>>> > aimed to pd's hilbert~ abstraction by the way.
>>>>> >
>>>>> > cheers
>>>>> >
>>>>> > 2016-06-22 17:27 GMT-03:00 katja <katjavet...@gmail.com>:
>>>>> >>
>>>>> >> Hi, Olli Niemitalou has coefficients published for a higher order
>>>>> >> 'hilbert transformer' on http://yehar.com/blog/, attached is [olli~]
>>>>> >> abstraction based on it.
>>>>> >>
>>>>> >> Katja
>>>>> >>
>>>>> >> On Wed, Jun 22, 2016 at 4:37 AM, Alexandre Torres Porres
>>>>> >> <por...@gmail.com> wrote:
>>>>> >> > Howdy, I'm working on a frequency shifter object (via single
>>>>> >> > sideband
>>>>> >> > modulation / complex modulation).
>>>>> >> >
>>>>> >> > In Max they have a so called "6th order hilbert transformer with a
>>>>> >> > minimum
>>>>> >> > of error". In Pd, the hilbert~ abstraction is 4th order. I'm
>>>>> >> > copying the
>>>>> >> > pd
>>>>> >> > abstraction for now, but I was hoping to use such a higher order
>>>>> >> > filter
>>>>> >> > and
>>>>> >> > also use- but I can't find a source for such a formula. Any help
>>>>> >> > finding
>>>>> >> > it?
>>>>> >> >
>>>>> >> > thanks
>>>>> >> >
>>>>> >> > ___
>>>>> >> > 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] A 6th order hilbert transformer?

[katja]

Hi, Olli Niemitalou has coefficients published for a higher order
'hilbert transformer' on http://yehar.com/blog/, attached is [olli~]
abstraction based on it.

Katja

On Wed, Jun 22, 2016 at 4:37 AM, Alexandre Torres Porres
<por...@gmail.com> wrote:
> Howdy, I'm working on a frequency shifter object (via single sideband
> modulation / complex modulation).
>
> In Max they have a so called "6th order hilbert transformer with a minimum
> of error". In Pd, the hilbert~ abstraction is 4th order. I'm copying the pd
> abstraction for now, but I was hoping to use such a higher order filter and
> also use- but I can't find a source for such a formula. Any help finding it?
>
> thanks
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
#N canvas 534 105 496 308 10;
#X obj 254 75 delay~ 1 1;
#X obj 254 46 inlet~;
#X obj 29 227 outlet~;
#X obj 254 229 outlet~;
#X text 30 15 Olli Niemitalo's quadrature transformer;
#X text 27 279 y[n]=b1*y[n-1]+b2*y[n-2]+a0*x[n]+a1*x[n-1]+a2*x[n-2]
;
#X text 26 260 Pd's biquad:;
#X obj 29 102 biquad~ 0 0.161758 0.161758 0 -1;
#X obj 29 131 biquad~ 0 0.733029 0.733029 0 -1;
#X obj 29 163 biquad~ 0 0.94535 0.94535 0 -1;
#X obj 254 102 biquad~ 0 0.479401 0.479401 0 -1;
#X obj 254 132 biquad~ 0 0.876218 0.876218 0 -1;
#X obj 254 164 biquad~ 0 0.976599 0.976599 0 -1;
#X obj 254 192 biquad~ 0 0.9975 0.9975 0 -1;
#X text 81 228 first phase;
#X text 310 228 second phase;
#X text 157 228 << 90 degree >>;
#X obj 29 190 biquad~ 0 0.990598 0.990598 0 -1;
#X connect 0 0 10 0;
#X connect 1 0 0 0;
#X connect 1 0 7 0;
#X connect 7 0 8 0;
#X connect 8 0 9 0;
#X connect 9 0 17 0;
#X connect 10 0 11 0;
#X connect 11 0 12 0;
#X connect 12 0 13 0;
#X connect 13 0 3 0;
#X connect 17 0 2 0;
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] pd list mailing archive?

[katja]

Search for "gigaverb~" instead and you'll find it.

Katja

On Tue, May 31, 2016 at 12:57 PM, José Rafael Subía Valdez
<jsubiaval...@gmail.com> wrote:
> Hmmm... maybe mine is leaky or leakier than I expected. I thought I read
> about someone porting it to PD and wanting to put it up with deken.
>
> no worries, thanks for the help
>
> On Tue, May 31, 2016 at 11:12 AM, IOhannes m zmoelnig <zmoel...@iem.at>
> wrote:
>>
>> On 2016-05-31 11:53, José Rafael Subía Valdez wrote:
>> > Hello List,
>> >
>> > I have been checking the mail archive (
>> > http://www.mail-archive.com/pd-list@iem.at/) to find a thread about
>> > "gverb~" that someone posted a while back, but definitely this year,
>> > however, the archive goes up to 2014. Does anyone know where I can find
>> > the
>> > latest archive? or maybe someone knows where the gverb~ thread is, or
>> > the
>> > author??
>>
>> how about using
>>  https://lists.puredata.info/pipermail/pd-list
>> i think (but then i implemented it) that the search functionality has
>> improved a lot, e.g. it allows you to search all (Pd-related)
>> mailinglists.
>>
>> in any case, it doesn't find anything about gverb~ this year, which
>> matches my own memory (which is leaky).
>>
>> fgmasdr
>> IOhannes
>>
>>
>>
>> >
>> > thank you all
>> >
>> >
>> >
>> >
>> > ___
>> > 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
>>
>
>
>
> --
> José Rafael Subía Valdez
> www.jrsv.net
>
>
>
>
>
> ___
> 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] [Scope~] (was Re: can signal inlets that aren't the main inlet have float or message methods?)

[katja]

I notice there used to be one help patch indeed for all nettles, as in
Fred Jan's version. For a good reason as we now see. Alexandre has
created individual help patches for each nettles class. These could
better be encapsulated within nettles-help.pd, rather than live as
separate files.

Katja

On Sun, Apr 10, 2016 at 12:34 PM, katja <katjavet...@gmail.com> wrote:
> Hello Derek,
>
> The problem is with the following help files added by Alexandre:
>
> <~-help.pd
> <=~-help.pd
>>~-help.pd
>>=~-help.pd
>
> You could filter these out from the wildcard search in the makefile
> and instead list them explicitly, between quotes like:
>
> "help/<~-help.pd"
>
> Alternatively you could make a single help patch 'nettles-help.pd' and
> use function class_sethelpsymbol() in all nettles classes. This is
> probably a better solution, avoiding more file name problems in the
> future.
>
> Katja
>
> On Sun, Apr 10, 2016 at 1:29 AM, Derek Kwan <derek.x.k...@gmail.com> wrote:
>>>
>>> The symlinks aren't created at compile time but during the install
>>> process. It is done by target 'install-aliases'. Do 'make install
>>> objectsdir=./build' to get a local install. If you still get no
>>> symlinks let me know.
>>>
>>> I think they are only needed on Linux because of how file access happens.
>>>
>>> Katja
>>> >
>>
>> Great! Thanks. Yeah, that works.
>>
>> When I'm doing the local install, I'm getting this error:
>>
>> Makefile.pdlibbuilder:1013: recipe for target 'install-datafiles' failed
>> make: *** [install-datafiles] Error 2
>>
>> I haven't checked too thoroughly but it looks like everything is
>> building. I'm sudo-ing it if that makes a difference.
>>
>> Derek
>> =
>> Derek Kwan
>> www.derekxkwan.com

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

Re: [PD] [Scope~] (was Re: can signal inlets that aren't the main inlet have float or message methods?)

[katja]

Hello Derek,

The problem is with the following help files added by Alexandre:

<~-help.pd
<=~-help.pd
>~-help.pd
>=~-help.pd

You could filter these out from the wildcard search in the makefile
and instead list them explicitly, between quotes like:

"help/<~-help.pd"

Alternatively you could make a single help patch 'nettles-help.pd' and
use function class_sethelpsymbol() in all nettles classes. This is
probably a better solution, avoiding more file name problems in the
future.

Katja

On Sun, Apr 10, 2016 at 1:29 AM, Derek Kwan <derek.x.k...@gmail.com> wrote:
>>
>> The symlinks aren't created at compile time but during the install
>> process. It is done by target 'install-aliases'. Do 'make install
>> objectsdir=./build' to get a local install. If you still get no
>> symlinks let me know.
>>
>> I think they are only needed on Linux because of how file access happens.
>>
>> Katja
>> >
>
> Great! Thanks. Yeah, that works.
>
> When I'm doing the local install, I'm getting this error:
>
> Makefile.pdlibbuilder:1013: recipe for target 'install-datafiles' failed
> make: *** [install-datafiles] Error 2
>
> I haven't checked too thoroughly but it looks like everything is
> building. I'm sudo-ing it if that makes a difference.
>
> Derek
> =
> Derek Kwan
> www.derekxkwan.com

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

Re: [PD] [Scope~] (was Re: can signal inlets that aren't the main inlet have float or message methods?)

[katja]

Hello Derek,

The symlinks aren't created at compile time but during the install
process. It is done by target 'install-aliases'. Do 'make install
objectsdir=./build' to get a local install. If you still get no
symlinks let me know.

I think they are only needed on Linux because of how file access happens.

Katja

On Sat, Apr 9, 2016 at 12:01 PM, Derek Kwan <derek.x.k...@gmail.com> wrote:
>> On Fri, Apr 8, 2016 at 10:52 PM, IOhannes m zmölnig <zmoel...@iem.at> wrote:
>> > On 04/08/2016 10:29 PM, Alexandre Torres Porres wrote:
>> >> Then, cyclone does not come as a library for a long time, and "Scope~" is
>> >> not part of a "-lib"
>> >
>> > but it is!
>> > it is part of a library named "Scope~.pd_linux" which contains a single
>> > object "Scope~".
>>
>> He's building 'scope~.pd_linux'. With a symlink 'Scope~.pd_linux' and
>> the alias in the C code, wouldn't that be all right?
>> >
>> > mdsf
>> > IOhannes
>> >
>>
>
> Hello,
>
> I'll chime in here because I've been working on this cyclone update as
> well (Alexandre, hop in here if I'm wrong about any of this). To my
> knowledge, there isn't any symlinking going on in the build process. I'm
> using Ubuntu on my machine and I just built it myself and all I get out
> for scope is scope~.pd_linux. All references to Scope has been changed
> to scope in Makefile and the source (sickle/Scope.c) got changed to
> sickle/scope.c. There's no symlink to scope~.pd_linux at all. Do we want
> to change the Makefile to build a symlink to the built scope~ (and also,
> what are the reasons for doing so)? Also. is there a symlink equivalent
> for Windows machines? I'll be honest, I'm not really familiar with
> Makefile building beyond the very basic stuff (I didn't even know you
> could make symlinks in Makefiles for instance)...
>
> Derek
>
> =
> Derek Kwan
> www.derekxkwan.com

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

Re: [PD] [Scope~] (was Re: can signal inlets that aren't the main inlet have float or message methods?)

[katja]

On Fri, Apr 8, 2016 at 10:52 PM, IOhannes m zmölnig  wrote:
> On 04/08/2016 10:29 PM, Alexandre Torres Porres wrote:
>> Then, cyclone does not come as a library for a long time, and "Scope~" is
>> not part of a "-lib"
>
> but it is!
> it is part of a library named "Scope~.pd_linux" which contains a single
> object "Scope~".

He's building 'scope~.pd_linux'. With a symlink 'Scope~.pd_linux' and
the alias in the C code, wouldn't that be all right?
>
> mdsf
> IOhannes
>
>
> ___
> 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] [Scope~] (was Re: can signal inlets that aren't the main inlet have float or message methods?)

[katja]

Alexandre, it seems you found a good approach to gradually phase out
upper case (when not needed to avoid name clash). If you change class
name and aliases the C code don't forget to swap upper / lower case in
the symlinks too, which are created for Linux under 'cyclone extra
targets' in the Makefile.

Katja

On Fri, Apr 8, 2016 at 10:29 PM, Alexandre Torres Porres
<por...@gmail.com> wrote:
> 2016-04-08 16:11 GMT-03:00 Jonathan Wilkes <jancs...@yahoo.com>:
>>
>> if the user isn't loading cyclone by default, and their patch does this:
>> [declare -lib cyclone/Scope~]
>
>
> Ok, but what would that do in the first place? I don't think I get [declare]
> yet, can you find a specific individual binary or object inside a library?
>
> Then, cyclone does not come as a library for a long time, and "Scope~" is
> not part of a "-lib"
>
>>
>> If by "traded" you mean you renamed the binary to scope~.pd_linux, this
>> won't load anymore.
>
>
> Nope, I changed stuff in the code as well
>
> I might be wrong, but it seems possible to change it and maintain backwards
> compatibility and get rid of this annoying Capital letter, but I'm
> consulting you guys to be sure.
>
>
>>
>>  you still need  "Append" to differentiate from the internal "append"
>> class, so you can't change that one.
>
>
> Things, to my surprise, things work in a new and weird way to me in Pd
> Vanilla. Any class you call that is not the internal one overwrites the
> internal library. I discussed this on a previous thread these days (Name
> conflicts "class overwritten; old one renamed 'x_aliased').
>
> The way things are in cyclone nowadays, and I had given the example of
> "line~" is that it has the "Line~" official and legacy name version but also
> calls the objects as alias "line~" or "cyclone/line~"
>
>>
>> Also-- why is there a class_addcreator to add "cyclone/*" for each class?
>> That _should_ be superfluous...
>
>
> It's not for every class, but these one with name clashing issues.
>
> So, anyway. How things are now, if I call "Line~", internally it will find
> the alias "line~" and load it overwritting vanilla's line~. That sucks cause
> they're not compatible. And basically you had this Capital letter in the
> first place to avoid name clashing and it was clashing it anyway... (yeah,
> quite ironic).
>
> It seems that this system would allow you to load cyclone/line~ in Pd
> Extended and Pd-L2ork, because in both of them, there is no internal
> overwritting going on. So latest version of extended (0.43) introduced this
> system with the alias. You can call [cyclone/uzi] and [cyclone/line~] for
> example, but the latter won't overwritte the internal vanilla's line~
>
> By the "Uzi" is another example like "Scope~", some Capital letter for some
> reason that is not relevant anymore... and yeah, Uzi comes with the aliases
> "uzi" e "cyclone/uzi".
>
> But back to "Line~"
>
> if I remove the alias "cyclone/line~" I can now call [Line~] or
> [cyclone/line~] in Pd without overwritting the internal, and being able to
> differentiate between [line~] (internal) and [cyclone/line~] external. This
> is the same case as with Append. I think we should keep the weird animal
> "Line~" as an alias and an option over [cyclone/line~].
>
> But Uzi and Scope~ are in another category, they don't overwrite internals.
> In Pd-L2ork you have an old version of Scope~ without the alias, so you
> won't be able to load it as "scope~" or "cyclone/scope~", but [Uzi] is
> updated, so you can call it as [uzi] or [cyclone/uzi]. I can only test this
> in Mac Os, but with the version you provided today, I can do it. Can you do
> it in linux and windows?
>
> Anyway, I assume that if they did it in Pd Extended, it was for the reason
> that the trick worked for every system, or they wouldn't introduce this
> madness or massive inconsistency. And my thought is, if you can do it one
> way to the other, you can also do it the other way around... if I can call
> "uzi" as an alias, then I can call "Uzi" as an alias as well.
>
> So, getting Uzi as an example, if I switch everything to the opposite like
> this:
>
> void uzi_setup(void) { uzi_class = class_new(gensym("uzi") (...)
> class_addcreator((t_newmethod)uzi_new, gensym("Uzi"), A_DEFFLOAT, 0);
> class_addcreator((t_newmethod)uzi_new, gensym("cyclone/Uzi"), A_DEFFLOAT, 0)
> (...)
>
> void Uzi_setup(void) {  uzi_setup(); }
>
> Plus the code 

Re: [PD] know if audio is in patch?

[katja]

In [output~] included with cyclone it always works. The fix was
introduced a while ago but after Pd-E's last release.

Katja

On Wed, Mar 30, 2016 at 5:10 PM, Matt Barber <brbrof...@gmail.com> wrote:
> It will only work after the first time dsp is set with one of those
> [output~] objects loaded, though, right?
>
> On Wed, Mar 30, 2016 at 10:56 AM, Alexandre Torres Porres <por...@gmail.com>
> wrote:
>>
>> yep, it's for patches without [output~] - but I didn't really know it had
>> that kind os (and similar) logic, thanks
>>
>> cheers
>>
>> 2016-03-30 5:29 GMT-03:00 katja <katjavet...@gmail.com>:
>>>
>>> Alexandre, a dsp switch with similar functionality is already embedded
>>> in cyclone's output~.pd abstraction. See subroutine [pd dsp logic].
>>> Maybe you didn't see it working because the toggle is so small? The
>>> GUI is equivalent to Pd-extended's shared output~.pd. You could give
>>> the toggle a contrasting color or resize to catch attention. In any
>>> case there's no need to put an extra dsp switch in patches with
>>> output~.pd.
>>>
>>> Katja
>>>
>>> On Tue, Mar 29, 2016 at 9:17 PM, Alexandre Torres Porres
>>> <por...@gmail.com> wrote:
>>> > sure, had to work on it ;)
>>> >
>>> > this is based on pddp/dsp for a series of help patches that will be
>>> > on/off
>>> > according to dsp state
>>> >
>>> > cheers
>>> >
>>> > 2016-03-29 3:40 GMT-03:00 IOhannes m zmoelnig <zmoel...@iem.at>:
>>> >>
>>> >> On 2016-03-29 01:53, Alexandre Torres Porres wrote:
>>> >> > well, found a way
>>> >>
>>> >> sigh...
>>> >> do you mind sharing your findings, so that other people may know as
>>> >> well?
>>> >>
>>> >> fgm,asdr
>>> >> 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
>>> >
>>
>>
>>
>> ___
>> 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] know if audio is in patch?

[katja]

Alexandre, a dsp switch with similar functionality is already embedded
in cyclone's output~.pd abstraction. See subroutine [pd dsp logic].
Maybe you didn't see it working because the toggle is so small? The
GUI is equivalent to Pd-extended's shared output~.pd. You could give
the toggle a contrasting color or resize to catch attention. In any
case there's no need to put an extra dsp switch in patches with
output~.pd.

Katja

On Tue, Mar 29, 2016 at 9:17 PM, Alexandre Torres Porres
<por...@gmail.com> wrote:
> sure, had to work on it ;)
>
> this is based on pddp/dsp for a series of help patches that will be on/off
> according to dsp state
>
> cheers
>
> 2016-03-29 3:40 GMT-03:00 IOhannes m zmoelnig <zmoel...@iem.at>:
>>
>> On 2016-03-29 01:53, Alexandre Torres Porres wrote:
>> > well, found a way
>>
>> sigh...
>> do you mind sharing your findings, so that other people may know as well?
>>
>> fgm,asdr
>> 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
>

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

Re: [PD] raspberry pi window position problem

[katja]

On Raspbian Jessie you should get puredata 0.46.2 with apt-get
install. Check what info you get with command 'apt-cache show
puredata'. If it shows another version than 0.46.2, something may be
wrong with your repository settings, which could affect other packages
too.

Katja

On Wed, Mar 23, 2016 at 10:47 AM, oliver <oli...@klingt.org> wrote:
> Julian Brooks wrote:
>>
>> Hey Sam! Great to hear you're lurking:) I think it was our first go's
>> on your Pi when we encountered this.
>>
>> Can I ask what RPi model's this is with and which version of
>> Raspbian?
>>
>> While we can sort hacks for Pd it should presumably be an O.S./W.M.
>> fix.
>>
>> I've never encountered this problem on various debian wheezy installs
>>  but that's with xfce not lxde.
>>
>>
>
>
> hi, small update:
>
> for whatever reason, my recently "apt-get installed" puredata was version
> 0.43 (how so ?)
>
> i manually installed 0.46 and voilà: problem gone !
>
> cheers
>
> oliver
>
>
>
>
> ___
> 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] LKFS or LUFS-based compression?

[katja]

Ah, sorry for my completely irrelevant pointer. Now I understand
(after consulting wikipedia again) that you want to compress according
to frequency- and sound pressure dependent equal-loudness contours so
you can comply with standards about perceived loudness? Seems that
this requires multiband RMS detection and weighting.

Katja

On Wed, Mar 16, 2016 at 10:20 AM, William Huston
<williamahus...@gmail.com> wrote:
> Thanks Katja.
>
> I did not intend to imply a particular compression method.
>
> I was only asking if anyone has created
> a compressor in Pd with the goal of limiting based
> on Average Loudness rather than Peak Gain.
>
> I don't really know how it works,
> except to guess it is related to
> Fletcher–Munson curves.
>
> I want to get into broadcast more.
> A LKFS or LUFS external (meter and compressor)
> would be very useful.
>
> Limiting based on Loudness is becoming
> both a US and EUR broadcast standard,
> yet there aren't many tools out there,
> it seems.
>
>
>
> On Wed, Mar 16, 2016 at 5:01 AM, katja <katjavet...@gmail.com> wrote:
>>
>> Frankly I had to ask Wikipedia what LKFS and LUFS is. They are
>> loudness standards, they don't indicate compression method.
>>
>> Here's a peculiar method which uses detection of instantaneous
>> amplitudes instead of peak sample values:
>>
>> http://www.katjaas.nl/compander/compander.html
>>
>> From an engineer's viewpoint this approach is highly debatable and you
>> wouldn't use it for all purposes. But it reacts super fast to
>> transients. I use it on acoustic input in live performance.
>>
>> Katja
>>
>> On Wed, Mar 16, 2016 at 7:51 AM, William Huston
>> <williamahus...@gmail.com> wrote:
>> > Has anyone played around with LKFS or LUFS-based
>> > "Loudness Compression"?
>> >
>> > This would be a really handy thing to have
>> > for anyone who creates audio for broadcast TV or Radio,
>> > or movie scores, etc.
>> >
>> > When people grab a compressor, this is what
>> > we mostly want. However, in my experience,
>> > most compressors are peak-level compressors.
>> >
>> > Thanks for any leads/pointers.
>> >
>> >
>> > --
>> > --
>> > May you, and all beings
>> > be happy and free from suffering :)
>> > -- ancient Buddhist Prayer (Metta)
>> >
>> > ___
>> > Pd-list@lists.iem.at mailing list
>> > UNSUBSCRIBE and account-management ->
>> > http://lists.puredata.info/listinfo/pd-list
>> >
>
>
>
>
> --
> --
> May you, and all beings
> be happy and free from suffering :)
> -- ancient Buddhist Prayer (Metta)

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

Re: [PD] LKFS or LUFS-based compression?

[katja]

Frankly I had to ask Wikipedia what LKFS and LUFS is. They are
loudness standards, they don't indicate compression method.

Here's a peculiar method which uses detection of instantaneous
amplitudes instead of peak sample values:

http://www.katjaas.nl/compander/compander.html

From an engineer's viewpoint this approach is highly debatable and you
wouldn't use it for all purposes. But it reacts super fast to
transients. I use it on acoustic input in live performance.

Katja

On Wed, Mar 16, 2016 at 7:51 AM, William Huston
<williamahus...@gmail.com> wrote:
> Has anyone played around with LKFS or LUFS-based
> "Loudness Compression"?
>
> This would be a really handy thing to have
> for anyone who creates audio for broadcast TV or Radio,
> or movie scores, etc.
>
> When people grab a compressor, this is what
> we mostly want. However, in my experience,
> most compressors are peak-level compressors.
>
> Thanks for any leads/pointers.
>
>
> --
> --
> May you, and all beings
> be happy and free from suffering :)
> -- ancient Buddhist Prayer (Metta)
>
> ___
> 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] some notes for cyclone devs / maintainers

[katja]

On Wed, Feb 24, 2016 at 7:06 PM, Alexandre Torres Porres
<por...@gmail.com> wrote:
> 2016-02-24 14:17 GMT-03:00 katja <katjavet...@gmail.com>:
>>
>> the code was embedded in the programming structure of miXed, together with
>> other libraries and the shared framework (...) Since other libraries in
>> miXed were essentially unmaintained (...) I figured that cyclone's chances
>> for future maintenance would be best if it could be compiled with a build
>> system not relying on Pd-X or miXed as a set of libraries.
>
>
> Makes sense to me.
>
> Well, first, thanks for all the detailed information on how cyclone grew
> into a giant kludge and current issues Katjia. So, It was brought to github
> conserving as many pieces of the original puzzle as possible. But well,
> yeah, seems like depending on old ways and days might be counterproductive
> on the long run as you mentioned.  and it kinda relates to what Miller and
> others were telling about how cyclone should maybe be left alone as it was
> attached to "old ways of doing things", a new rebuild might be a good idea,
> though quite ambitious.

Alexandre, your summary of my notes about cyclone's build systems (old
and new) make a totally different story than I was telling. Cyclone
didn't grow into a kludge, only the build system did. That is now
solved as far as I am concerned.

For the rest: cyclone and it's underlying framework form a
well-structured but never completed body of code. I don't think anyone
suggested to rewrite it, if that is what you mean with 'rebuild'.
Rewriting is ambitious indeed, possibly beyond your imagination. And a
waste of time. Better focus on new functionality, and leave or
delegate maintenance of the existing code base to people who are able
and willing to understand it's structure.

Katja

>
>>
>> Of course it is technically possible to add new classes which don't
>> use the framework functions (...) You can have independent repositories,
>> test / release cycles, and support (...) if the outcome of the discussion is
>> that all must go in one cyclone lib, you could at least organize source tree
>> and build system in such a way that dependencies between categories of
>> classes and underlying framework remain transparent. The build system could
>> be split according to categories of classes so devs can work in relative
>> isolation in between releases.
>
>
> For now, I'm revising all the documentation and painstakingly correcting it
> and testing objects looking for current issues. I've covered one third of
> the audio objects to this moment (26), only 8 have no remarks. This is a
> very time consuming task. I might take a month to recheck all current state
> of objects.
>
> I can propose a new beta release with minor bug fixes right away just for a
> test, keeping things basically the way they already were. There's time to
> think about everything else when this new report of the current state is
> complete.
>
>> here's my recommendation: make use of the new build
>> approach, because dealing with the old kludge of build scripts in
>> miXed won't make you happy in the long run.
>
>
> Agreed, thanks for the notes again.
>
> Cheers

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

[PD] some notes for cyclone devs / maintainers

[katja]

Independent from the question who will contribute to cyclone in the
future and whose repository will be considered upstream I'd like to
share a few practical remarks on the build systems. In the old days I
would have sent this to pd-dev list but that may not be seen by
everyone involved now. A conversation can be redirected later.

Just like a library of books is more than a shelf with someone's
favorites, cyclone is more than a collection of Pd classes. For the
user it serves as a bridge between Pd and MaxMSP, but under the hood
it has consistency too, in the form of a specific framework. Pd users
don't need to know about hammer, sickle etc. as an interface to Pd,
but cyclone maintainers can't ignore it.

When Fred Jan started fixing bugs in cyclone, the code was embedded in
the programming structure of miXed, together with other libraries and
the shared framework. I got involved a bit later, with the
self-imposed task to develop a generalized build method for Pd
libraries that could support a complex source tree layout like
cyclone's. Since other libraries in miXed were essentially
unmaintained, with the exception of pddp which was forked inside
Pd-X's source tree earlier, I figured that cyclone's chances for
future maintenance would be best if it could be compiled with a build
system not relying on Pd-X or miXed as a set of libraries.

Cyclone's build system had over the years grown into an impenetrable
web of makefiles in miXed and Pd-X's library root dir. In the time
when Krzysztof Czaja started miXed, gnu make wasn't so '''advanced'''
as nowadays and he used some nifty tricks to design an expandable
build system, which in the end wasn't so expandable because no one
else could understand the tricks.

Today we have slightly more options for meta programming in gnu make,
notably the 'eval' function. The newly developed build method for
cyclone uses Makefile.pdlibbuilder, a generalized helper makefile for
Pd libraries big or small. Of course this helper makefile uses nifty
tricks too which aren't understood by everyone. But the calling
library makefile is transparent. And easily expandable.

An early version of the new build method was committed to SVN. When
IOhannes facilitated decentralization of Pd-extended with svn>git
conversion for all libraries, Fred Jan took cyclone to github for
continued maintenance. Technically speaking it is a fork, and
effectively it got split off from miXed. We've been considerate with
the structure and underlying framework though, conserving as many
pieces of the puzzle as could be put  together. Fred Jan reanimated a
part of cyclone that was lost to oblivion for a some years (nettles).
The makefile gives insight how class files per category relate to
dependencies in hammer, sickle etc.

Of course it is technically possible to add new classes which don't
use the framework functions. There are suggestions to start a new
library for new classes which follow a different code structure.
Indeed a split between classes using the framework and classes not
using it could simplify development. You can have independent
repositories, test / release cycles, and support. Cloning MaxMSP is
ambitious enough to justify division into sub projects. However if the
outcome of the discussion is that all must go in one cyclone lib, you
could at least organize source tree and build system in such a way
that dependencies between categories of classes and underlying
framework remain transparent. The build system could be split
according to categories of classes so devs can work in relative
isolation inbetween releases.

I'm not planning to participate in cyclone development myself, since
Makefile.pdlibbuilder is a big enough project for me to maintain,
apart from my personal Pd work. It is now unknown if cyclone will be
maintained as an individual library in its own repository or in a
larger context like Pd-L2Ork where it is still embedded in miXed. In
any case, here's my recommendation: make use of the new build
approach, because dealing with the old kludge of build scripts in
miXed won't make you happy in the long run.

Katja

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

Re: [PD] freeverb~ problem

[katja]

If the freeverb~ version you use looks like the one in
http://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/freeverb~/freeverb~.c,
there's a function 'fix_denorm_nan_float() defined starting at line
154. The function is called later (in line 225 and others) but the
return value is never stored. Therefore freeverb~ doesn't flush
denormals.

On Sat, Feb 6, 2016 at 3:34 PM, Ivica Bukvic <i...@vt.edu> wrote:
> Thank you all. Looks like I've got some troubleshooting to do and will
> report what I find.
>
> Best,
>
> --
> Ivica Ico Bukvic, D.M.A.
> Associate Professor
> Computer Music
> ICAT Senior Fellow
> Director -- DISIS, L2Ork
> Virginia Tech
> School of Performing Arts – 0141
> Blacksburg, VA 24061
> (540) 231-6139
> i...@vt.edu
> www.performingarts.vt.edu
> disis.icat.vt.edu
> l2ork.icat.vt.edu
> ico.bukvic.net
>
> On Feb 6, 2016 9:20 AM, "IOhannes m zmölnig" <zmoel...@iem.at> wrote:
>>
>> On 02/06/2016 10:29 AM, katja wrote:
>> > Possibly an inf or nan recirculating in the delay lines? It seems that
>> > freeverb~ calls function fix_denorm_nan_float(float v) but doesn't use
>> > the return value.
>>
>> you *might* be able to confirm this by sending the output for
>> [freeverb~] to [print~] (the silent samples would be NaN or Inf rather
>> than 0 (or some other constant value))
>>
>> gamds
>> 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
>

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

Re: [PD] freeverb~ problem

[katja]

Possibly an inf or nan recirculating in the delay lines? It seems that
freeverb~ calls function fix_denorm_nan_float(float v) but doesn't use
the return value.

On Sat, Feb 6, 2016 at 7:54 AM, Simon Iten  wrote:
> i assume you did already try the gainreducing before freeverb and gainboost 
> after? [*~ 0.01] —> [freeverb~] —> [*~100] for example
> i had some problems with signals that were too “loud”, they were cured with 
> this.
>
> so, not the cause but a possible workaround.
>
>> On 06 Feb 2016, at 06:20, Ivica Ico Bukvic  wrote:
>>
>> All,
>>
>> I've encountered a new issue with freeverb~. I am having a hard time 
>> isolating the source as it happens so sporadically (although it is always 
>> linked with the sudden drop in input and possibly a low frequency impulse) 
>> but it does not seem like it is a denormal problem because when it happens, 
>> I get a small burst of noise followed by nothing even though CPU is not 
>> getting pegged. The rest of the patch works fine but the freeverb is for all 
>> intents and purposes dead. It does not do anything until it is deleted and 
>> recreated. Any ideas what may be the cause of this? In the said example I 
>> only use one input (left). Could that have to do something with it? The 
>> object is compiled on 64-bit Linux with -O2 optimizations (IIRC).
>>
>> Best,
>>
>> --
>> Ivica Ico Bukvic, D.M.A.
>> Associate Professor
>> Creative Technologies in Music
>> ICAT Senior Fellow
>> Director -- DISIS, L2Ork
>> Virginia Tech
>> School of Performing Arts – 0141
>> Blacksburg, VA 24061
>> (540) 231-6139
>> www.performingarts.vt.edu
>> disis.music.vt.edu
>> l2ork.music.vt.edu
>> ico.bukvic.net
>>
>>
>> ___
>> 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

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

Re: [PD] pd for c.h.i.p.

[katja]

Congratulations, if you get it today. The kickstarter blog doesn't
provide technical info. Better look here:

http://docs.getchip.com/#introduction

It says that CHIP runs a Debian system. You can install package
puredata through Synaptic (is pre-installed), or through command
apt-get. I bet it's also possible to use Miller's RPi builds.

If you install puredata from repository (Synaptic, apt-get) you could
disable recommended dependencies, being GEM in this case, which will
not work on CHIP anyway.

Keep us updated!

Katja

On Tue, Jan 19, 2016 at 7:04 PM, Alexandre Torres Porres
<por...@gmail.com> wrote:
> hi, I'm getting my c.h.i.p. in the mail today, anybody else is checking this
> new board?
>
> https://www.kickstarter.com/projects/1598272670/chip-the-worlds-first-9-computer
>
> My greatest interest is, of course, installing Pd in it, I wonder if anyone
> else is compiling Pd for it and if there are plans to offer a compiled
> version for its system
>
> thanks
>
> ___
> 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] Array List View

[katja]

On Fri, Jan 1, 2016 at 8:24 PM, katja <katjavet...@gmail.com> wrote:
> Hi Jonathan,
>
> Your concept is a great improvement over built-in array list view. It
> is now a very useful debug tool since you can jump to any desired
> index no matter how long the array is.
...

Before someone else points out the incorrectness of this statement
I'll do it myself: not all indexes above 2^24 can be accessed, because
of imprecision. This is everything above ~ 6 min 20 seconds at SR
44100.

Katja

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

Re: [PD] Array List View

[katja]

Hi Jonathan,

Your concept is a great improvement over built-in array list view. It
is now a very useful debug tool since you can jump to any desired
index no matter how long the array is. Thank you for this new year's
present.

I figured out some refinements. Attached version has:

- buttons: offset inc / dec by 1 or 10, set to min / max offset, refresh
- inlet for offset, refresh, and array name message
- outlets for index / value pairs and offset
- toggle to activate console printout

It is temporarily called 'arraylistview2' for evaluation, and a patch
with tests is included in the tarball. An issue with the name anyhow
is confusion between 'arraylistview' and 'arrayviewlist'. Pd's
built-in method goes with message 'arrayviewlistnew'. Maybe it could
be a completely different name, like 'tabviewer'.

Jonathan, your approach makes me realize once more how powerful Pd is
as a framework / language for dsp prototyping. Imagine a whole
collection of debug instruments along the same line, like zoom viewer,
spectrum viewer etc. Each tool would do a small job and they could be
chained together by array name and index offset. Yummy.

cheers,
Katja


On Wed, Dec 30, 2015 at 4:15 AM, Jonathan Wilkes <jancs...@yahoo.com> wrote:
> I did some revisions on an abstraction replacement for the listview button
> in
> the array dialog.
>
> Rather than hook into a button buried in a dialog, I'm going to just throw
> the
> abstraction in "extra" somewhere.  That's about as discoverable as it
> currently
> is, plus one could use it as a control in a patch if they wish.  But the
> best part
> is that it requires zero code in the core/GUI, opening up revisions and
> bugfixes to anyone who can write a Pd patch.
>
> Improvements welcome, as well as shorter abstraction name (as long as it's
> obscure enough not to clash with anything else).
>
> -Jonathan
>
>
> On Thursday, November 19, 2015 12:20 PM, Jonathan Wilkes via Pd-list
> <pd-list@lists.iem.at> wrote:
>
>
> That's just a matter of creating a single number box and connecting its
> output to [s $0-offset].
>
> Well, there's bounds checking, too-- the point is it's all just a Pd patch
> so you're unlikely to crash Pd by revising the functionality.  Plus the
> barrier
> to entry is much lower than the small number of people who can untangle
> garray-related spaghetti code.
>
> -Jonathan
>
>
>
> On Friday, November 13, 2015 4:00 AM, katja <katjavet...@gmail.com> wrote:
>
>
> That looks good Jonathan. In current array list view the entries are grouped
> per 1000 and arrows let you switch groups. For 'large' arrays (say one
> second of audio samples) this is inconvenient. Maybe your patch approach
> could even provide a better solution, like the option to select a specific
> range.
>
> There's also method 'arrayviewclose' which I sometimes (ab)use to close a
> list view from within a patch. You don't want to try update an audio array
> list view in real time!
>
> On Fri, Nov 13, 2015 at 1:32 AM, Jonathan Wilkes <jancs...@yahoo.com> wrote:
>
> I don't know.  Something like this with the guts hidden?
>
> I didn't do the hard stuff, like handling out-of-bounds elements if the
> array isn't a multiple of ten-- it's just a prototype.
>
> So, in that method you and katja are abusing, I can forward the arrayname
> as well as the current $0 count.  Then I can open the patch and immediately
> send a message to the relevant $0- receiver, and the patch will populate the
> value table accordingly.
>
> And then I can get rid of all the arraylistview C/GUI code that's scattered
> about.
>
> -Jonathan
>
>
>
>
>
> On Thursday, November 12, 2015 4:55 PM, Matt Barber <brbrof...@gmail.com>
> wrote:
>
>
> A Pd patch with what in it?
>
> On Thu, Nov 12, 2015 at 4:21 PM, katja <katjavet...@gmail.com> wrote:
>
>
>
> On Thu, Nov 12, 2015 at 8:36 PM, Jonathan Wilkes <jancs...@yahoo.com> wrote:
>
> Would you mind if this opened a Pd patch instead of a tk dialog?
>
>
> Could be OK if the list is editable, like current array list view.
>
> Katja
>
>
>
>
>
>
>
>
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>


arraylistview.tar.gz
Description: GNU Zip compressed data
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] consolidate backward- and MaxMSP compatibility in Cyclone (was: Purpose of Cyclone)

[katja]

On Wed, Dec 23, 2015 at 4:44 AM, Dan Wilcox <danomat...@gmail.com> wrote:
> What about versioning? If people *have* to have older compatibility, then
> why can’t they just run an older version of cyclone? Newer development can
> take place on the current version and you can clearly note api
> changes/updates in a CHANGELOG. Say tag cyclone right now as version 1.0.0
> and all further development is version 2.0.*

Versioning is important but it can't solve all issues that arise when
diverging. While it is easy for a user to update to a specified
version of a library with deken, Pd patches already out there 'in the
wild' (to quote Jonathan) don't specify which version they need.

Katja

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

Re: [PD] consolidate backward- and MaxMSP compatibility in Cyclone (was: Purpose of Cyclone)

[katja]

On Tue, Dec 22, 2015 at 11:51 PM, Alexandre Torres Porres
<por...@gmail.com> wrote:
> Well, newer patches with newer functionalities not working in older versions
> is how things go anyway, right? Vanilla 0-46 patches don't run in 0.45 and
> so on... there's no way around that I guess.

Right, in this context it is worth noting that any improvement in a
library has the potential of causing problems for people who use an
old version, yet it doesn't prevent us from fixing bugs.

Recall cyclone/count~ which used to make Pd crash when receiving the
'set' message. Everyone learned to not send it that message. Now that
the bug is fixed people may start using the set message, causing
spurious crashes for those who use the patch with an old cyclone
version. Oddly, the crasher bug fix may lead to a temporary increase
of crash incidents. The remedy is simple for everyone; upgrade to the
latest cyclone.

Extrapolating this to other improvements (an extra feature in a class
or a new class in a library): as long as you improve and add, it's
safe for everyone to simply use 'latest'. In contrast, if you take
away, things become amazingly complicated. Oddly again, this may be a
reason to not introduce an improvement or addition too quickly. You
want to be pretty sure you don't need to take it away later.

Katja

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

Re: [PD] consolidate backward- and MaxMSP compatibility in Cyclone (was: Purpose of Cyclone)

[katja]

On Tue, Dec 22, 2015 at 9:41 PM, Alexandre Torres Porres
<por...@gmail.com> wrote:

> If we're discussing [average~], how about my idea of having a second right
> signal outlet as default? I think it's an easy and simple solution. Help
> file would explain how the left control outlet is for backwards
> compatibility. Done.

Yes that would be an easy way to incorporate Fred Jan's signal average
output into the existing class. But note that both solutions, dual
mode and dual outlet, have a similar forward incompatibility effect. A
patch that uses the right signal outlet of a new version won't run
with an old average~ binary. So the pros and cons of both solutions
are comparable, with the small difference that the dual outlet layout
with message left and signal right is rather unusual.

Katja

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

[PD] consolidate backward- and MaxMSP compatibility in Cyclone (was: Purpose of Cyclone)

[katja]

Hello Alexandre, Fred Jan, pd list,

It makes me sad to see your earlier productive collaboration on
Cyclone stagnating with this dispute about the purpose. Between 2005 -
2015 the purpose of Cyclone has been determined more by what it was
than by what it should be, by lack of human resources [1]. With the
recent increased effort of testing, fixing and innovation there's an
opportunity to redefine intentions and ambitions. Let's try to figure
out a generic approach where backward compatibility doesn't conflict
with MaxMSP compatibility and innovation, so anyone can contribute to
the project according to their skill, interest and ambition.

My proposal would be to sacrifice forward compatibility of older
versions if needed. Classes which pose the compatibility dilemma may
be made to operate in multiple modes. Sometimes this can be achieved
by message, and when the number or type of inlets / outlets are
concerned (like average~) it can be achieved with creation arguments.

Now you have to decide which is the default behavior. With decades
worth of Pd patches in mind it seems logical to keep the original
Cyclone behavior as default and offer the MaxMSP compatible mode as an
alternative. The help patch demonstrates how to use the newly
developed mode. A class setup message can advertise it too.

There's always this caveat with introducing new message selectors and
creation arguments: old versions of the class don't support them so
you could still end up with broken patches. But this is less
problematic than backward incompatibility. The class help patch must
give clear information about the version where new functionality was
introduced, and anyone who applies it in a distributed Pd patch can
inform the user about version requirements. No spurious malfunctions,
but at worst a clear hint to upgrade.

You may wonder what is my own involvement with Cyclone. At the moment,
none apart from following the discussion. Earlier this year I spent a
few months developing Makefile.pdlibbuilder as a generic build system
for Pd libs. Replacing the indecipherable build system of Cyclone was
the ultimate test case for this work, and it helped speed up Fred
Jan's work on the library. I became aware how big a project it really
is. It could use the love and care of more people besides Alexandre
and Fred Jan.

Katja

[1].
Cyclone (part of miXed) was unfortunately abandoned by it's original
author Krzysztof Czaja after 2005. The ambitions with this wonderful
project were then in practice scaled down to fixing bugs in the alpha
versions, as illustrated by the commit history of it's SVN repository
http://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/miXed/cyclone/.

On Mon, Dec 21, 2015 at 6:26 PM, Alexandre Torres Porres
<por...@gmail.com> wrote:
>
> 2015-12-15 16:22 GMT-02:00 Fred Jan Kraan <fjkr...@xs4all.nl>:
>>
>> Hi Alexandre,
>>>>
>>>> Compatibility is limited to a very old version of Max/MSP.
>>>
>>>
>>> That really confused me, as a Max 7 user...
>>
>>
>> Why? If any version of Max/MSP looks like Pd, it is 4.6 (or maybe earlier
>> versions, but I don't have access to those...).
>
>
> Because it is not a matter on how it "looks", and Max 7 is still the same
> patching environment, it's not like it changed and lost compatibility, hence
> I'm using both Max 7 and cyclone and I'm happy about it.
>
> It's not like Max 7 killed and broke backwards compatibilty with earlier
> versions and patches. So we don't have to consider it as having to be tied
> to 4.6..
>
> Perhaps you mean we'll never be able to come close to what Max 7 is now in
> general. But I don't think that was ever possible and the purpose of cyclone
> was not to make a clone of the Max/MSP Software.
>
> I think this is a very serious and sensitive topic, as the purpose of
> cyclone is not being really considered in your point of view, and this might
> interferes with the purpose, or even kill it...
>
>>>>
>>>> For me this makes backward compatibility more important
>>>> than with an obsolete Max/MSP version.
>
>
> If I got it right, you're basically saying:
>
> - Cyclone should be a copy of an outdated and obsolete Max/MSP version and
> we shouldn't care on keeping up with improvements in Max because it is
> impossible and only really likely or reasonably possible within the
> limitations of max/msp 4.6 as a software.
>
> - Not caring about the developments in earlier versions of Max, we're stuck
> to 4.6, but since it is an obsolete version of Max, we shouldn't care about
> being faithful to it either, or Max for that matter.
>
> Thus, we'd basically lose the idea of having a library of objects compatible
> to Max/Msp objects, and we also do not care of the original purpose of it.
> Well, that is

Re: [PD] fat binaries or not, on OSX (was: 'Pd 64 bits' for OSX is i386 + ppc)

[katja]

On Tue, Dec 15, 2015 at 9:56 AM, IOhannes m zmoelnig <zmoel...@iem.at> wrote:
> On 2015-12-13 23:16, katja wrote:
>> iven to both compiler and linker:
>>
>> -arch i386 -arch x86_64 -mmacosx-version-min=10.5
>>
>> One thing I noticed when building fat binaries: gcc doesn't define
>> __i386__ or __x86_64__ which we use to conditionally compile bithacks.
>
> ?are you sure?
>
> $ cc --version
> i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
> $ cat > testarch.c < #include 
> int main() {
> #ifdef __i386__
>   printf("i386\n");
> #endif
> #ifdef __x86_64__
>   printf("x86_64\n");
> #endif
>   return 0;
> }
> EOL
> $ make testarch CFLAGS="-arch i386 -arch x86_64 -mmacosx-version-min=10.5"
> $ ./testarch
> x86_64
> $ arch -i386 ./testarch
> i386
> $ arch -x86_64 ./testarch
> x86_64
> $

This looks good, thanks for proving me wrong. Which OSX version is
this? I've had troubles with denormals in fat binaries in the past
(OSX 10.5). It turned out that the preprocessor didn't pass
architecture defines when preprocessing for multiple architectures.
The behavior has apparently changed with compiler version. I'll look
into this matter again.

>
>> For this reason I'm now thinking that single-architecture should be
>> the default in a generic build system, and fat binary an option.
>
> dunno.
> i think that the default should be to just use the system-defaults
> (don't tell the compiler which architecture it should build for).
> this is driven by the experience with tehe template/Makefile: there are
> a number of externals out there that don't build on recent OSX, because
> the original template-Makefile would build for PowerPC and apple dropped
> out-of-the-box support for ppc.
>
> otoh. it's obviously of utmost importance that any thus-compiled
> external loads correctly under a "default" Pd installation.
>
> so for practical reasons it's probably best to use i386/x86_64 (and
> don't enable PPC by default)

On 'recent' OSX (>= 10.6) Makefile.pdlibbuilder builds i386 / x86_64
by default, no ppc. For OSX 10.5 the default includes ppc which was
still supported at that time. OSX 10.5 can build the fattest binaries
out of the box. But I didn't include ppc 64 bit (yet) as I've never
had an opportunity to test that.

>
> fgmadr
> 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] fat binaries or not, on OSX (was: 'Pd 64 bits' for OSX is i386 + ppc)

[katja]

If Pd externals could be built for PDP11, I would support it in
Makefile.pdlibbuilder.

Even when very few people still use Apple ppc it's nice to be able to
support it. But not at the expense of other platforms of course. If
you (or anyone else) encounter specific problems when building on OSX
10.5 because of the ppc target architecture, please report on
https://github.com/pure-data/pd-lib-builder. On later OSX versions it
won't try to build for ppc so for most people this goes unnoticed.

If instead you object to the distribution of combined ppc/intel
binaries via deken, that is a different matter going beyond discussion
of the makefile.

Katja

On Tue, Dec 15, 2015 at 7:57 PM, Dan Wilcox <danomat...@gmail.com> wrote:
> My 2 cents:
>
> Honestly, I *really* wouldn’t bother with maintaining ppc support anymore.
> 10.5 was released in Oct of 2007, that’s 6 versions ago and 99.9% of people
> running OSX are not running ppc. I understand the desire to support it, but
> those people can use older versions of Pd. Without going down the “Apple
> forces planned obsolesce, blah blah” fest again, the practical matter is
> that the need for OSX ppc is so small I feel developer effort is best spent
> elsewhere. Besides, if I were resurrecting an old Power PC G5 Mac Pro, I’d
> install Debian on it anyway.
>
> OTOH, if you personally have an old Powerbook and want to keep Pd on it up
> to date, go for it! I’m just suggesting, if that’s not the case, it may not
> be worth the extra time and effort.
>
> 
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
>
> On Dec 15, 2015, at 4:00 AM, pd-list-requ...@lists.iem.at wrote:
>
> On 'recent' OSX (>= 10.6) Makefile.pdlibbuilder builds i386 / x86_64
> by default, no ppc. For OSX 10.5 the default includes ppc which was
> still supported at that time. OSX 10.5 can build the fattest binaries
> out of the box. But I didn't include ppc 64 bit (yet) as I've never
> had an opportunity to test that.
>
>

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

[PD] fat binaries or not, on OSX (was: 'Pd 64 bits' for OSX is i386 + ppc)

[katja]

Thanks for your explanation. I checked the "real" programs in
Pd-0.46-7-64bit/Contents/Resources/bin/pd, they are x86_64 indeed.
Those in Pd-0.46-7/Contents/Resources/bin/pd are i386 and ppc.

Also I noticed the externals extension (for bonk~ etc.) is .d_fat in
both cases. Will that be your default extension for OSX? Do you
consider distributing Pd for OSX as 32 / 64 bit fat binary in the
future? Or even ppc + i386 + x86_64 (which can be built conveniently
on OSX 10.5)?

I'm trying to figure out what sort of binaries Makefile.pdlibbuider
should best build by default on OSX, hence these questions. We need a
strategy to maximize chances that distributed Pd's and externals are
compatible.

cheers,
Katja

On Sun, Dec 13, 2015 at 3:17 AM, Miller Puckette <m...@ucsd.edu> wrote:
> The "GUI" program (Pd.../Contents/MacOS/Pd) is a copy of the wish shell,
> and is i386/ppc... but the "real" programs in Pd.../Contents/Resources/bin/pd
> seem to me to be x86_64 - if not I must have distributed the wrong file 
> somehow.
>
> cheers
> Miller
>
> On Sat, Dec 12, 2015 at 10:16:56PM +0100, katja wrote:
>> Hello,
>>
>> From Miller's site I downloaded "Pd version 0.46-7, 64 bits, compiled
>> for Macintosh OSX 10.8 or later (4 Megabytes)". Checking for target
>> architecture with command 'file', it is reported to be a fat binary
>> for i386 and ppc. Though the application will load all right, it
>> doesn't seem to be the build that is advertised.
>>
>> 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] fat binaries or not, on OSX (was: 'Pd 64 bits' for OSX is i386 + ppc)

[katja]

On Sun, Dec 13, 2015 at 6:56 PM, Miller Puckette <m...@ucsd.edu> wrote:
> At the moment, my best idea is to have "fat" externs (i386 and ia64) that
> can be loaded by either 32 or 64-bit versions of Pd.  But I'd like to be
> able to do two other things I don't know how to do yet:
>
> Have a single version of Pd that can run in 32 or 64 bits

Currently Makefile.pdlibbuilder (which isn't used much yet) tries to
build fat binaries by default. OSX 10.5 with Xcode 3.1 can build the
fattest (ppc and Intel, 32 and 64 bit). Later configurations can build
for Intel 32 and 64 bit. In that case the following flags must be
given to both compiler and linker:

-arch i386 -arch x86_64 -mmacosx-version-min=10.5

One thing I noticed when building fat binaries: gcc doesn't define
__i386__ or __x86_64__ which we use to conditionally compile bithacks.
For this reason I'm now thinking that single-architecture should be
the default in a generic build system, and fat binary an option.


>
> simultaneously enable 64 bit versions with 32 or 64 bit floating samples
>
> The second thing would complicate loading of externs since I don't know how
> to make a fat binary with two different alternative code sections that are
> chosen according to the directions of the loading program - at the moment
> loading is on the basis of architcture (and which code segment to load os
> chosen automatically by the OS on that basis).

IOhannes has suggested ideas about loading 'phat' (fat precision)
binaries in a pd-dev thread starting here:

http://lists.puredata.info/pipermail/pd-dev/2015-02/020073.html (and further)

Katja


>
> cheers
> Miller
>
> On Sun, Dec 13, 2015 at 11:37:35AM +0100, katja wrote:
>> Thanks for your explanation. I checked the "real" programs in
>> Pd-0.46-7-64bit/Contents/Resources/bin/pd, they are x86_64 indeed.
>> Those in Pd-0.46-7/Contents/Resources/bin/pd are i386 and ppc.
>>
>> Also I noticed the externals extension (for bonk~ etc.) is .d_fat in
>> both cases. Will that be your default extension for OSX? Do you
>> consider distributing Pd for OSX as 32 / 64 bit fat binary in the
>> future? Or even ppc + i386 + x86_64 (which can be built conveniently
>> on OSX 10.5)?
>>
>> I'm trying to figure out what sort of binaries Makefile.pdlibbuider
>> should best build by default on OSX, hence these questions. We need a
>> strategy to maximize chances that distributed Pd's and externals are
>> compatible.
>>
>> cheers,
>> Katja
>>
>> On Sun, Dec 13, 2015 at 3:17 AM, Miller Puckette <m...@ucsd.edu> wrote:
>> > The "GUI" program (Pd.../Contents/MacOS/Pd) is a copy of the wish shell,
>> > and is i386/ppc... but the "real" programs in 
>> > Pd.../Contents/Resources/bin/pd
>> > seem to me to be x86_64 - if not I must have distributed the wrong file 
>> > somehow.
>> >
>> > cheers
>> > Miller
>> >
>> > On Sat, Dec 12, 2015 at 10:16:56PM +0100, katja wrote:
>> >> Hello,
>> >>
>> >> From Miller's site I downloaded "Pd version 0.46-7, 64 bits, compiled
>> >> for Macintosh OSX 10.8 or later (4 Megabytes)". Checking for target
>> >> architecture with command 'file', it is reported to be a fat binary
>> >> for i386 and ppc. Though the application will load all right, it
>> >> doesn't seem to be the build that is advertised.
>> >>
>> >> 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

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

Re: [PD] Cyclone issues update

[katja]

On Mon, Dec 7, 2015 at 9:14 PM, Alexandre Torres Porres
<por...@gmail.com> wrote:
> Great & Awesome, Thanks!
>
> But please allow me to make a suggestion and start a discussion.

[snip]

> I'm fine in having some flexibility and not having the exact same
> functionality as in max, we could have other functionalities/features, so
> having two outlets could be meeting halfway - I just tend to criticize this
> need to maintain features and behaviours that emerged from mistakes and then
> adding other stuff around it and making it more complicating than just
> fixing it.
>
> Anyway, those are my thoughts on it, anybody else?

In my view backward compatibility should be taken very serious in the
case of any Pd class. I find it really annoying when classes change
their behavior for anything other than a very compelling reason.
Here's why: among the people who use Pd patches that we distribute,
not everyone is so much aware of details discussed on Pd list, and
then they don't know why a patch breaks.

You wouldn't believe how long a broken patch stays around. I've found
the broken version of my patch SliceJockey on many people's computers,
even months or years after I had uploaded a fixed version.

Hence my opinion: don't break backward compatibility unless you really
must, like when a class produces incorrect mathematical results.

Katja

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

Re: [PD] 64 bit audio?

[katja]

This topic keeps popping up on Pd list with stable frequency. Here's a
text about the effects of double precision in Pd:

http://www.katjaas.nl/doubleprecision/doubleprecision.html

It illustrates that double precision as Pd's basic data type will
improve results for very specific cases (like reading long buffers,
subsonic filtering), but it comes at a price to be payed by everyone
all of the time. In terms of performance penalty, the price seemed to
be acceptable at the time of writing (2011). That was before the
advent of pico computers like Raspberry Pi, for which the price of
doubles is much higher. Also I realized only later that making _all_
external libs double-precision-aware is mission impossible.

Since you can't mix single precision Pd with double precision
externals or vice versa, you can imagine what a hairy expedition it
is. As I see it now, a double precision build is mainly valuable for
evaluation. It helps finding out how important precision is for some
routine, and may even provide insights which help to fix some
precision issue within the constraints of single precision Pd. Here's
a video where you can see double precision Pd in action (in the latter
part):

https://www.youtube.com/watch?v=93632nc8LVs

Katja

On Fri, Nov 27, 2015 at 5:09 AM, Alexandre Torres Porres
<por...@gmail.com> wrote:
> not much attention here, but here's an anser from the SC list about their
> discussion in porting the audio server to 64 bits
>
> "The biggest advantage of higher resolution is in things like filter loops,
> but most SC UGens already do 64 bit calculations internally where that’s
> appropriate"
>
> I guess it makes sense, 32 bit is more than enough for dealing with audio
> signals/amplitudes.
>
> So I assume Pd won't likely bother to become 64 bits like Max did for
> similar reasons, and maybe just think "internal 64 bit calculations" sooner
> or later, or does that already happen?
>
> cheers
>
>
>
> 2015-11-25 4:26 GMT-02:00 Alexandre Torres Porres <por...@gmail.com>:
>>
>> This may already have been discussed on the list I guess, but I wonder if
>> there's any plan to have Pd running audio (and control) signals at 64 bit
>> audio in the near coming future.
>>
>> I know there's a version you can compile with double precision for a while
>> now, and I'm just wondering if we should naturally expect that this will
>> eventually happen as a default, because that is the natural course to go, or
>> "not at all"...
>>
>> One way or another, I was hoping for some explanation why it would likely
>> and naturally go towards a 64 bit resolution or not (technical issues / pros
>> & cons).
>>
>> thanks
>>
>>
>
>
> ___
> 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