Pd-list November 2002

pd-list@lists.iem.at

99 participants
141 discussions

RE: [pd] IRC
by wwcarpen 30 Nov '02

30 Nov '02

just my 2 cents about irc, i happen to know the person who has been sitting in #pure-data on efnet for the last year or so. unfortunatly i don't think he reads this list so he can't really organize anything. It seems like often someone will join and then leave when they don't see anyone around, but i bet that if some people just idled a bit, people would begin meeting eachother. I'm a big fan of PD and it definatly needs a place for users to chat about everything, i know there is probably a lot of people who want to. wwcarpen

5 5

Re: [PD] bitmap sequencer and flext png library wrapper (fwd)
by Mathieu Bouchard 30 Nov '02

30 Nov '02

I am sending this back on the list because my address gets blocked by your mailserver for some obscure reason. ---------- Forwarded message ---------- Date: Fri, 29 Nov 2002 19:26:00 -0500 (EST) From: Mathieu Bouchard <matju(a)sympatico.ca> To: rfigura(a)metabit.com Cc: Alexandre Castonguay <acastonguay(a)artengine.ca> Subject: Re: [PD] bitmap sequencer and flext png library wrapper On Fri, 29 Nov 2002, Robert Figura wrote: > Okayokayokayokay i _will_ take a look. I am very grateful for that =) > #0 0x402a2802 in st_lookup (table=0x0, key=0x150 <Address 0x150 out of bounds>, value=0xbfffafc8) at st.c:253 > #1 0x40250265 in search_method (klass=1079530340, id=336, origin=0xbfffb004) at eval.c:250 It means that some ruby-class has been blown up by memory corruption. "table" is a null-pointer when it should not be. The problem is not with "key", because although "key" is probably a void* here, it's not being used as a true pointer. > #4 0x40254f3c in rb_eval (self=1079619060, n=0x405991c0) at eval.c:2544 Unfortunately we can't get to Ruby's line numbers easily with GNU-Debugger, and I don't know how. But: > #28 0x4025a339 in rb_funcall (recv=1079670760, mid=9897, n=0) at eval.c:4688 > #29 0x40243cfa in gf_timer_handler__FP6_clockPv (alarm=0x0, obj=0x0) at base/bridge_puredata.c:384 It means that we're in GF's event loop. > $ ltrace pd-debug -noaudio -nogui -open test.pd 2> trace.log I never thought of using ltrace... thanks. Ruby makes a lot of allocations/operations by itself that might not be (directly) relevant to what GridFlow does. > memcpy(0x0812a720, "method call on terminated object", 32) = 0x0812a720 This is a very important message. This means we have a dangling pointer problem. However that might be only the symptom of some other memory corruption. > memcpy(0x08116e90, "Ruby-for-PureData:0", 19) = 0x08116e90 This is GridFlow's toplevel trapping the error. > ### in #4 ruby_frame says: > file = "gridflow/base/MainLoop.rb" > line = 178 oops, i forgot i could look at that information. It is not very useful, as it points to a very ordinary expression. > ahem. how to trace what is in ruby_block? (and why?) Okay i guess this > year i will not find out what the function was libruby tried to call. > (must have been tick, but that does not seem to matter) i see no way > to spot the bug analytically. now lets attack the code. remove > everything until we know what could be the problem... I don't know the problem is anywhere close to that spot in the code anyway. What shall be inspected thoroughly, imho, are anything running in the initialization phase of gridflow, because i can get PD and jMax to crash without loading any patch in a few seconds by setting the timer rate high enough. > first clear FObject_s_install_2 (hope this will avoid installing any > objects in case one of the objects is defect.) - still coredump By clearing, you mean disabling all of its code? "install" is not all that may go wrong. There are other portions of initialization that happen outside of "install". "install" is just the final registering of a class with PD/jMax, but at that point, the class is already registered with Ruby, and before that the class may have had its own C++-level initialization. > btw: what is that timer_handler for? It is mostly used for checking X11 events, TCP transfers (when they did work), [rtmetro], and such. > 16 hours later: > Wherever i cut down a feature the error goes somewhere else. It could > be ruby (i still have problems watching it's internal structures - and > that's where the errors always come from) That kind of wanton behaviour is typical of memory corruption bugs. It looks as if the guilty piece of code is blameshifting, deceiving. A self-concealing bug. One that says "I didn't do it!" and you don't know where that voice comes from. This is why I called for help first. > Bridge is a confusing tohuwabohu, you never know what data is going to > ruby (all these id's and lists). Ruby has no separate process so you > never know if ruby was poison or pd. I am not going to learn ruby from > inside. The whole GridFlow/PD bridge is eight pages and is pretty close to being the smallest piece of code possible that can do what it does. ID's are possibly a leftover from older versions of Ruby. It's part of the Ruby API and I can't do much against them. There are a few global variables that could become of type ID which could save a few conversions. Lists are also essential. Most GridFlow patches uses lists as messages or as arguments in a constructor. In addition, an argument list is a list, and a named message is also a list... The bridge supports recursive lists in case one wants to code a Ruby object that accepts recursive lists. > Giving up. I'd suggest a complete rewrite. I can't consider a complete rewrite unless I have a good idea of how much different it would be. The way it is now is quite close to the precise idea I have of it. Of course I have plans about big changes to the architecture, but those are not clear ideas as much as they are dreams. Maybe one of the bigger things to consider would be the use of SWIG for the C++ <-> Ruby bridging. However, some kind of feasibility study would be required: I have the impression that SWIG won't support everything I need to, or that there will be some kind of significant overhead. Another solution might be the use of Ruby/DL, which is a different approach to the same problem of wrapping libraries, but I don't know how ready that is, and whether it works with C++ code, and whether it works with Ruby 1.6 (Ruby 1.7 is considered experimental). > I didn't like the setjmp stuff either so bitmap_png.cc reads a png then > copies the data and then destroys the pnglib structures in a single > function. That's okay. Most of GF's format-handlers are doing too. > The bitmap design is different (and so is the purpose). It works > pixel-wise (!) so the only latency happens on read/write. This sounds like GridFlow 0.1.x ... that was over 1.5 year ago. > as i can see pd uses backtracking in the scheduler. if you ask two > questions the first one will get completed first. a delay(0) aborts > descending and continues on the next iteration. so you could connect > your operators using message delays. I don't understand this paragraph. > Another way would be to put the operators in a thread and let them > asynchronously activate their outlets. I'll begin considering threading eventually, but so many features have priority that it is not likely you'll see anything about it in 2003; that is, unless I get superpowers, of course. ________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju

1 0

Re: [PD-announce] pd 0.36 test 9
by marius schebella 29 Nov '02

29 Nov '02

hi miller, there is still a problem with "keyup", which is triggering on keydown-event. marius. > This fixes several problems, including the "keyname" bug.

2 1

Order of cabling
by matthew jones 29 Nov '02

29 Nov '02

Anyone got an example/help-file that explains the intricacies of how the order in which you place cables affects the order in which the operation is done? I attempted some 'further' maths last night with the standard pd functions and although I finally got it to work, there were definitely some very strange things going on, even though I was attempting to control the ordering/flow with many bangs. Some things that should have worked didn't at all, so I ended up backing up and finding another way to do it.... and another.

4 4

Detecting the bpm of an audio input
by arm pdlist 29 Nov '02

29 Nov '02

Sorry if this is a newbie question (or dumb) but i'm just starting to use pd, so... :) In my search for a sensor to detect the heart rate, and after talking to a teacher of mine, he suggested that a very sensitive mic would something to consider as a source for the heart beats. No comes que question. I have a small mic that i connected to my laptop. I can get the signal in PD. But how can i detect the bpm of a signal that is coming from adc~ object? I'm just touching on the mic to simulate the heart beat, but would be possible to detect some kind of bpm of the signal? If so, what do i have to do? Can you give some links where i can get some more info on what i should do? Thanks. __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com

4 3

windows dosbox problems with nogui
by André Schmidt 29 Nov '02

29 Nov '02

hi ppl, i tried (the first time) pd with the flag "-nogui" and was first scared how slow it opened GrIPD. but i remebered something about adding object [netreceive] in your patch and voila, it all works smooth... but, 1. when i close GrIPD and then close the "dosbox" i get the "furious blue screen" on my win2k machine (yes, i know. it says somethig like "don't close this window when using midiin". but i dont know any other way how to close the dosbox without pd-gui... help!) 2. can i run pd without the dosbox ? (eg. using/seeing only GrIPD) well, the important info i would need is how do i close the dosbox (with out blue screen :) when using pd with -nogui flag... 1000thnx -andre ps. i'm using pd0.35-1

2 2

Re: [PD] Sample counter
by CK 29 Nov '02

29 Nov '02

ooops sorry, forgot some sort of counter obviously ... I wrote: > > I read: > > sort of counter that counts number of samples (ie NOT miliseconds) since > > banged.......... > > how about [bang~] > | [counter] from gem or abstraction or whatever | > [* your_blocksize] HTH x -- chris(a)lo-res.org Postmodernism is german romanticism with better http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)

1 0

Re: [PD] Sample counter
by CK 29 Nov '02

29 Nov '02

I read: > sort of counter that counts number of samples (ie NOT miliseconds) since > banged.......... how about [bang~] | [* your_blocksize] regards, x -- chris(a)lo-res.org Postmodernism is german romanticism with better http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)

1 0

Sample counter
by matthew jones 29 Nov '02

29 Nov '02

sorry, being dumb probably (oh erm, thanks so much to everyone who answred my other clearly dumb questions...all answers seemed to work perfectly...seems some people actually DO know too much) but I need some sort of counter that counts number of samples (ie NOT miliseconds) since banged.......... surely there is some built-in function with which I have not become acquainted yet??

1 0

tktcllibs,linux and workaround
by Malte Steiner 29 Nov '02

29 Nov '02

Hello, maybe you already know but actually I face some trouble with installing PD on Mandrake 9. I can install but how mentioned in the docs, it misses the libtk and libtcl. Workaround making a symbolic link to libtk.so.0 and libtcl.so.0, that are the libs that are missed (and not libtk.so/ libtcl.so which are there). Greetings, Malte -- Malte Steiner -www.block4.com- next events: 18.-30. november artist in residency @ Access Space Sheffield,UK 25. november Hallam University Sheffield, UK 14. december Elektronengehirn live @ Künstlerhaus Sootbörn, Hamburg, Germany 28. december Elektronengehirn live @ Hoerbar, Hamburg, Germany current release: Elektronengehirn: contribution for THE DOOR CD Sampler new on block4: Xyramat 'Electronically'

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list November 2002