Pd-dev November 2002

pd-dev@lists.iem.at

36 participants
46 discussions

three pending buglets (was: [PD-announce] pd 0.36 test 9)
by Krzysztof Czaja 26 Nov '02

26 Nov '02

hi Miller, in case these were lost, buried under a pile of list traffic -- 1. Either sched_geteventno() need to be renamed to sys_geteventno() in m_obj.c, or it might be done the other way around in m_pd.h. 2. Either canvas_rename_method() should deal with A_DOLLSYM, or canvas_rename() itself might take an atom argument and perform the realizedollsym thing. 3. Either bendout should expect data in the 0..16383 range, or bendin's output should conform to the current bendout's range of -8192..8191. Krzysztof And -- do not know if this applies to other external developers, but I think it would be really nice to have PD_VERSION_... macros #defined somewhere in the main Pd src directory.

1 0

ggee: equalizer - bug?
by Ben Saylor 26 Nov '02

26 Nov '02

Hi Guenter + all, I was trying to build a graphic EQ using a chain of RBJ peaking filters (inspired by a message on music-dsp) and noticed that ggee's equalizer object doesn't seem to generate the right coefficients. I'm guessing it's supposed to be the peakingEQ from http://www.harmony-central.com/Computer/Programming/Audio-EQ-Cookbook.txt. The code in question is (ggee/filters/equalizer.c) t_float b0 = 1 + alpha*e_A(x->x_gain); t_float b1 = -2.*cos(omega); t_float b2 = 1; t_float a0 = 1 + alpha; t_float a1 = -2.*cos(omega); t_float a2 = 1 - alpha; but I think it should be t_float b0 = 1 + alpha * e_A(x->x_gain); t_float b1 = -2. * cos(omega); t_float b2 = 1 - alpha * e_A(x->x_gain); t_float a0 = 1 + alpha / e_A(x->x_gain); t_float a1 = -2. * cos(omega); t_float a2 = 1 - alpha / e_A(x->x_gain); After changing these lines, it behaves as expected (as a peaking filter, while before it was a funny-shaped peak with a notch beside it). Ben

2 1

0.36 in CVS
by guenter geiger 25 Nov '02

25 Nov '02

Hi, Just a short note, I have put version 0.36 test5 in CVS, merged with the patches from the devel_0_35 branch. to update: cvs update -r devel_0_36 ^^ This was done very quickly, I hope it worked ... Greetings, Guenter

2 1

Re: [PD-dev] yet another video processing external...
by Tom Schouten 25 Nov '02

25 Nov '02

> that's great !! thanks ;) > that's the first time i get > an acceptable frame rate in PD > and, that's funny because i was > planning to make such a package myself. > > by the way, do you plan to add audio support > one of these days ( this might be my little contribution ). > for live video (v4l) it should work the normal way: if the capture card or camera supports audio you can use that audio as a pd adc input. right now the capture is running continuously in another thread and a frame is output when a bang is received. so the audio and video should be synchronized. for the quicktime playback object, it is a bit different. the reason why is that the current qt playback object is frame based and externally synced using bangs, not stream based. so if you have some ideas on how to synchronize, let me know. one option could be to let it behave like sfread~ and let it output frames synced to the audio stream. but there are a lot more possibilities of course. another thing i was thinking about solving this problem in pd with seperate media files for video and audio, and writing an abstraction to handle sync for different types of playback. i think this option is better since it is a lot more flexible.. so to answer you're question i am leaving the problem open for the moment, but feel free to come up with a nice solution of course ;)

3 5

Re: [PD-dev] yet another video processing external...
by Tom Schouten 25 Nov '02

25 Nov '02

hi mick, that's exactly what i had in mind. i'd like to have a look at your external. tom > Hi, > > Saw this thread and remembered that I have an abstraction which does > this. > > The way I organised it, the audio for the file was given the same name > as the > video file (file1.avi = file1.avi.wav), and the message was passed > onto the > 'read' message (using list2symbol), loaded the file into the array(used > -maxsize so array wouldn't truncate the file), calculated the total > number of > samples, divided it by 44.1 (or whatever the sample rate was) and then > by the > total number of frames in the video file. Then your frame number can > be used > to control video and audio whilst maintaining perfect sync. I had to > adjust > the start frame so that the delay in frame display could be factored > out - the > number of frames depends on the codec. > > If you're interested in seeing it (it's a bit messy) i'll post it. > > hope this is of interest to you. > > Mick

1 0

[gem] [counter] wish : "skip numbers"
by André Schmidt 24 Nov '02

24 Nov '02

hi devs, would it be hard to code an "skip numbers" inlet for [counter] of gem ? ...that you could set how many numbers are skipped on bang :) cheers -andre

2 2

[berlin] prutal druth #2: impure data flow
by d.lj 23 Nov '02

23 Nov '02

[stefan kersten]->[Re: [OSC_dev] Re: [PD-ot] [berlin] prutal druth #2:... |Bryan Jurish wrote: |> well, i'm there .. | |yup, me too. | |> uh, where? | |see http://pd.iem.at/pdwiki/index.php?PrutalDruth hey, top. sorry for x-posting, but at least members of both lists are invited to drop by if possible. i hope a) you noticed that the date changed to 6th of dec (20021206) and b) that all of you have time in that slot as well. location is announced now (see wikilink above). programme has two members so far: * we re going to present the gullibloon project, abstractly as well as by means of 1 or 2 example applications. * possibly demo of some kind of data-headband, details follow. if any of you want to do a demo, performance or similar (2 - 20 min.?) let me know or just put it into http://pd.iem.at/pdwiki/index.php?PrutalDruth -> programme yourself. seoo thair_ -- i x Þ U . O R G

1 0

lists at right inlet
by David Sabine 23 Nov '02

23 Nov '02

Hello all, My experience with "m_pd.h" and its functions is still rather limited. I have a simple question. Is it possible to accept lists at a passive inlet (i.e. the RIGHT inlet if the object has only two inlets?) I can't find a definitive answer anywhere and I can't think of a single object in PD which already operates this way. Many thanks, Dave S

2 1

flext tutorial example signal2
by Thomas Grill 22 Nov '02

22 Nov '02

----- Original Message ----- From: "Adam T. Lindsay" <atl(a)comp.lancs.ac.uk> To: "Thomas Grill" <t.grill(a)gmx.net> Sent: Friday, November 22, 2002 12:23 PM Subject: Re: [PD] IEMLib status? > Oh, I noticed some runtime crashes with the tutorial: signal2. It crashes > hard whenever audio is turned on. I'll see what I can figure out from it. Wow, it's a bug in flext. But it only occurs when there are neither signal inlets nor outlets defined.. .which should be a rather rare case..... maybe the signal2 tutorial example is the only one.... greetings, Thomas

2 2

Re: cyclone-0.1-alpha1, s_loader.c, and MacOSX
by Adam T. Lindsay 22 Nov '02

22 Nov '02

Krzysztof, Miller, Krzysztof Czaja said this at Fri, 22 Nov 2002 16:37:44 +0100: >It seems like in each system Pd loads externals differently. >Windows .dll does not export external symbols, .pd_linux does >(with the flag RTLD_GLOBAL) -- but dlopen kindly resolves any name >clashes -- and now you tell that .pd_darwin is so fragile... You >are right, something needs to be done to unify loader's behaviour. Without knowing the full implications, I still advocate adding NSLINKMODULE_OPTION_PRIVATE for pd_darwin loading. At the very least, it prevents pd from crashing when loading GEM and maxlib at the same time. Not only that, but instantiating "scale" results in the scale object from the first-loaded library, which is reasonable behavior. (as opposed to a crash, which is fairly annoying when you're just trying to load libraries) Disclaimer: This is an empirical assessment, without a deep understanding of the loading system. But it seems to improve things. It doesn't *act* as fragile with the private symbols. Cheers, adam -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Adam T. Lindsay atl(a)comp.lancs.ac.uk Computing Dept, Lancaster University +44(0)1524/594.537 Lancaster, LA1 4YR, UK Fax:+44(0)1524/593.608 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 0

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 November 2002