Pd-dev June 2013

pd-dev@lists.iem.at

12 participants
15 discussions

Rewriting a unified phasor / metro object for reading tables
by Ed Kelly 07 Mar '14

07 Mar '14

Hi Lists(s), I'm rewriting phasor~ and unifying it with metro so that a pulse is generated from the boundaries of each ramp - so that bars of music can be read using tabread~ objects with a sample-accurate metro. I'm sure someone will say this can already be done, but it has to be dropped into the Ninja Jamm patch, so there isn't really time to rewrite the rest of the patch. I don't fully understand the way phasor~ wraps, but I have the object firing out bar numbers correctly. I'm putting clocks in for 16ths and 24ths of the beat, initiated on each wrap. I need to minimise CPU, so what I want to know is this: Does phasor~ always start from 0 and go to 1, i.e. is there always a signal value of 0 at the start of the ramp and a signal value of 1 at the end? As I write this, my common sense tells me it should be "yes" but I want to make sure. I suppose I should just try it really... Cheers, Ed Ninja Jamm - a revolutionary new musix remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/ Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/

8 10

Can't ping macosx105-i386.pdlab.puredata.info
by Antoine Villeret 03 Oct '13

03 Oct '13

hi all, I can't access anymore to macosx105-i386.pdlab.puredata.info (at least since yesterday) is it still alive ? thx antoine -- do it yourself http://antoine.villeret.free.fr

1 1

Midi overflow, when receiving Song Position Pointer (os x)
by Jan Baumgart 06 Aug '13

06 Aug '13

Hi there, I'm experiencing a severe bug, when sending a Song Position Pointer message (0x242 0 0) to pd. After sending just one SPP message to pd, the status window says: "warning: MIDI timing FIFO overflowed". When looking at the output of [midiin] I see "242 0 0 0" repeated endlessly. The Song Position Pointer message belongs to the System Common Messages and has two data bytes. Pd seems to get confused with this message. Where is the third data byte coming from? I'm running precompiled vanilla pd-0.44-3 from puckette's site on 32-bit intel mac (os x 10.6.8). I have a related second question: Is there any way to receive midi realtime messages with pd on os x? I'm trying to receive Midi Beat Clock... cheers, Jan

3 6

width control breaks parsing with [textfile]
by Roman Haefeli 03 Jul '13

03 Jul '13

Hi all The Pd file format might have its flaws, but I always enjoyed the fact that Pd files can be parsed with on-board tools like [textfile]. Using the same format (FUDI) for networking, file I/O, message passing makes a lot of things easier. Pd 0.45 is introducing a new feature to control width for objects/messages/comments. The way it is implemented breaks the ability to parse Pd files with [textfile]. The reason is that the format uses an un-escaped comma to delimit the object arguments from the object font/width properties. The following shows the original file data and after it has been sent from [textfile] to another and then saved: orig: #N canvas 613 117 450 300 10; #X floatatom 39 54 10 0 0 0 - - -, f 10; #X msg 122 145 f 31 \, f 31, f 37; the same 'parsed' by [textfile]: #N canvas 613 117 450 300 10 #X floatatom 39 54 10 0 0 0 - - - f 10 #X msg 122 145 f 31 \, f 31 f 37 I don't know any solution off-hand and I also don't know whether Pd was designed with the possibility in mind to read patches with [textfile]. I just want to have it mentioned. And yes, it does break some of my patches (not that this would be a reason not go forward and change Pd's file format). Roman

4 7

Include Header Files in Library Template Makefile
by Thomas Mayer 22 Jun '13

22 Jun '13

Hi, as I have upgraded PuREST JSON to using the latest Makefile from the library template, and I have header files for each source file, I propose the attached patch to include these in the library template Thanks, Thomas -- "Ich komme aus dem Staunen nicht heraus." "Dann bleib halt drin, du Seppel" (Dietmar Dath - Die Abschaffung der Arten) http://www.residuum.org/

1 0

remove tk scaling
by Jonathan Wilkes 20 Jun '13

20 Jun '13

Hi list, From tcl/pd-gui: # we are not using Tk scaling, so fix it to 1 on all platforms. This # guarantees that patches will be pixel-exact on every platform tk scaling 1 From #tcl on freenode: <jancsika> hello. does tk scaling affect canvas items? <ijchain> <emiliano> jancsika: no From my own experiments on Debian: * setting the tk scaling to 1, 0.2, 3, or 200 does not alter a canvas text item, either for positive (pointsize) font sizes or negative (pixelsize) font sizes * with version 8.5.11, setting tk scaling to 1, 0.2, 3, or 200 _will_ change the actual number of pixels a canvas requests from its parent _if_ you pack it without any option flags. (e.g., scaling at 0.2 will request a tiny rectangle and scaling at 200 will be bigger than the visible screen area, at least on my laptop). However, Pd packs its canvas items to fill the cavity provided by the toplevel parent (which always has its geometry set explicitly), so no matter what tk scaling value you set the canvas will be exactly the right size. You can check this by setting tk scaling to any value at all. The tk widgets will of course look different (that's what tk scaling affects, after all), but just click <ctrl-n> for a new patch and it will look exactly right. Also try: [label foo( | [vsl] ... and you will find that even iemguis have _exactly_ the same font size no matter what you provided for tk scaling. Effect of [tk scaling 1] command: causes tiny fonts in various widgets on Windows, which then requires a dev to fire up Pd on a Windows machine and screw around with the options database until they find the correct string to set the menufont Side effect: if you want to embed tk widgets in a patch, not having tk scaling frozen at "1" may end up making those widgets have different sizes on different platforms. But even with [tk scaling 1] you cannot guarantee pixel-exactness in this case, because tk uses native widgets from the OS, and different OSes will request different padding, font-sizes, images, etc. for those widgets. So-- is there any reason not to remove "tk scaling 1"? Thanks, Jonathan

4 17

OSX tcl/tk version
by Jonathan Wilkes 20 Jun '13

20 Jun '13

Can't figure this one out: Version: Pd 0.43.4extended OS: Mac OSX Version 10.7.5 1) Querying the tcl version with the tcl prompt: pdtk_post "[info patchlevel]\n" 8.5.11 2) Query OSX's wish version in a terminal: % info patchlevel 8.5.9 3) building a ttk::notebook through Pd's tcl prompt: toplevel .t pack [ttk::notebook .t.n] .t.n add [ttk::frame .t.n.f1] -text "hello" .t.n add [ttk::frame .t.n.f2] -text "world" You get the old "carbon" notebook that doesn't look native 4) building a ttk::notebook through OSX terminal wish prompt: (same as above) You get a "Tab View" as shown in Apple's HIG: https://developer.apple.com/library/mac/#documentation/UserExperience/Conce… Obviously I want the native "Tab View", but Pd won't give it to me. Version 8.5.9 and greater are supposed to hook into Cocoa for drawing native widgets. I assume 8.5.11 is greater than 8.5.9, so why is Pd displaying old-style Carbon widgets, and how do I change that behavior? -Jonathan

2 3

Re: [PD-dev] [PD] Makefile error in library template v1.0.14
by IOhannes m zmölnig 18 Jun '13

18 Jun '13

(moving this over to pd-dev) On 06/15/13 09:21, Joel Matthys wrote: > Hi Hans. > > The Makefile fails for Android on Linux 64 bit. I tracked it down to > line 149: > > $(NDK_BASE)/toolchains/$(NDK_ABI)*-$(NDK_COMPILER_VERSION)/prebuilt/$(NDK_UNAME)-x86) > > > should be: > > $(NDK_BASE)/toolchains/$(NDK_ABI)*-$(NDK_COMPILER_VERSION)/prebuilt/$(NDK_UNAME)-x86*) > > will this work if multiple toolchains are installed at the same time? (multiarch). fg,asdr IOhannes

2 1

Message dispatching system
by Jonathan Wilkes 17 Jun '13

17 Jun '13

Hi list, I learned some more about Pd's message dispatching system while adding jump-on-click mouse clicks and bar graphs to "Put" menu arrays: 1) For type-checked args in class_addmethod, you can specify them in any order. 2) Pd re-arranges them, putting the symbol/pointer args first and the float args last. 3) In the function for the method you have to specify the args in the order from #2. I see graph_array makes use of these in g_graph.c: the args are symbol float symbol float float, but the function receives the symbols as the first two args. Was this done to fix a bug or keep something backwards compatible? Are there other methods done this way? In general I think it's much better to specify type-checked args in the same order they'll be received by the function, meaning symbols/pointers then floats. Otherwise it makes it more difficult to track down errors. -Jonathan

2 3

Functional Programming & C code generation
by Tom Schouten 12 Jun '13

12 Jun '13

Hi Pd devs Is there anyone here interested in Functional Programming and C code generation for DSP code? I'm working on a system for DSP code development based on the principle of Abstract Interpretation http://en.wikipedia.org/wiki/Abstract_interpretation Basically, it will allow several interpretations of a single specification program: - specification as a pure functional program - imperative C code generation (for passing to C compiler or LLVM) - Z transform for frequency plots of (linearized) transfer function - automatic differentiation for all kinds of derivative-based tricks - ... It is written in Racket http://racket-lang.org/ It's starting to get to a point where it is actually useful (there is a basic synth core) and could use some feedback, but please note it is very experimental and still needs a lot of work. Familiarity with Racket is probably a prerequisite at this point to make sense of it. Current code is here: http://zwizwa.be/darcs/meta/rai/ It is part of a darcs archive that can be fetched using darcs gethttp://zwizwa.be/darcs/meta I use Pd for most of the experiments. There is a generator for Pd externs, and a "live coding" reload mechanism that can reload recompiled processing code without messing up internal state, as long as the types are compatible. Cheers Tom

3 8

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev June 2013