Pd-dev November 2009

pd-dev@lists.iem.at

19 participants
65 discussions

Re: [PD-dev] sourceforge not working ?
by Mathieu Bouchard 08 Nov '09

08 Nov '09

On Sun, 8 Nov 2009, Mathieu Bouchard wrote: > I tried submitting a bug in the pure-data project, but it cleared my form for > every mistake i made, but I only got to know they were mistakes once it > reported that my choice was invalid. If you pick "category" "None", your bug > report ("artifact") will be rejected and pressing "Back" clears the form. > > I tried writing that in the feedback form (http://sourceforge.net/feedback), > but it does not work at all, as it reports an error about "group_id", which > is a non-existent field in the feedback form, and then when i press the > "Back" button, again, the form is cleared. Actually, it did submit the artifact the first time, even though it really looked like it was getting rejected. so i submitted it twice. the second time, it got submitted as anonymous. That's also weird, because I don't know what I did in the meanwhile, but I didn't click "Log Out" for sure (!?). _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801

1 0

sourceforge not working ?
by Mathieu Bouchard 08 Nov '09

08 Nov '09

I tried submitting a bug in the pure-data project, but it cleared my form for every mistake i made, but I only got to know they were mistakes once it reported that my choice was invalid. If you pick "category" "None", your bug report ("artifact") will be rejected and pressing "Back" clears the form. I tried writing that in the feedback form (http://sourceforge.net/feedback), but it does not work at all, as it reports an error about "group_id", which is a non-existent field in the feedback form, and then when i press the "Back" button, again, the form is cleared. _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801

1 0

[ pure-data-Bugs-2894227 ] canvas_setgraph bug
by SourceForge.net 08 Nov '09

08 Nov '09

Bugs item #2894227, was opened at 2009-11-08 18:39 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2894227&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: v0.42 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: canvas_setgraph bug Initial Comment: canvas_setgraph can't go from flag=3 to flag=0 directly, else the objectbox stays uneditable, as if it were still a gop. this also affects the canvas properties dialogue ("hide object name" checkbox) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2894227&group_…

1 0

[ pure-data-Bugs-2894225 ] canvas_setgraph bug
by SourceForge.net 08 Nov '09

08 Nov '09

Bugs item #2894225, was opened at 2009-11-08 13:36 Message generated for change (Tracker Item Submitted) made by matju You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2894225&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: v0.42 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mathieu Bouchard (matju) Assigned to: Nobody/Anonymous (nobody) Summary: canvas_setgraph bug Initial Comment: with canvas_setgraph, setting flag=0 when flag=3 makes the objectbox non-editable even though it looks editable. the temporary workaround is to set flag=1. this also happens with the dialogue box ("hide object name and arguments" checkbox). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2894225&group_…

1 0

[ pure-data-Bugs-2893947 ] audio doesn't reconnect after sleep on Mac OS X
by SourceForge.net 07 Nov '09

07 Nov '09

Bugs item #2893947, was opened at 2009-11-07 16:23 Message generated for change (Tracker Item Submitted) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2893947&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: v0.42 Status: Open Resolution: None Priority: 6 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Nobody/Anonymous (nobody) Summary: audio doesn't reconnect after sleep on Mac OS X Initial Comment: If you have Pd open on Mac OS X, and the computer goes to sleep, Pd looses connection to the audio, and you either need to restart or select the audio API again in order to get sound. Mac OS X can send sleep/wake events, so Pd should register to get these, and use them to reconnect to the audio when the machine wakes up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2893947&group_…

1 0

install_name_tool fixes for Pd-extended 0.42.5 OSX
by Patrick Boivin 06 Nov '09

06 Nov '09

Hi, I just installed Pd-extended 0.42.5 auto-build from 2009-11-03 for OSX and it won't load Gem: /Applications/Pd-extended/Pd-0.42.5-extended-20091103.app/Contents/Resources/extra/Gem/Gem.pd_darwin: dlopen(/Applications/Pd-extended/Pd-0.42.5-extended-20091103.app/Contents/Resources/extra/Gem/Gem.pd_darwin, 10): Library not loaded: /sw/lib/libavutil.49.dylib Referenced from: /Applications/Pd-extended/Pd-0.42.5-extended-20091103.app/Contents/Resources/Scripts/../bin/../../lib/libavformat.52.dylib Reason: image not found Gem: can't load library It looks like it's just a couple of libs forgotten by install_name_tool fixes. Here's the relevant information from otool -L: libFLAC.8.dylib: /sw/lib/libogg.0.dylib (compatibility version 6.0.0, current version 6.3.0) libavformat.52.dylib: /sw/lib/libavutil.49.dylib (compatibility version 51.1.0, current version 51.1.0) /sw/lib/libavcodec.51.dylib (compatibility version 51.1.0, current version 51.1.0) /sw/lib/liba52.0.dylib (compatibility version 1.0.0, current version 1.0.0) /sw/lib/libamrnb.0.dylib (compatibility version 1.0.0, current version 1.0.0) /sw/lib/libfaac.0.dylib (compatibility version 1.0.0, current version 1.0.0) /sw/lib/libfaad.0.dylib (compatibility version 1.0.0, current version 1.0.0) /sw/lib/libmp3lame.0.dylib (compatibility version 1.0.0, current version 1.0.0) /sw/lib/libtheora.0.dylib (compatibility version 4.0.0, current version 4.4.0) /sw/lib/libogg.0.dylib (compatibility version 6.0.0, current version 6.3.0) /sw/lib/libvorbisenc.2.dylib (compatibility version 3.0.0, current version 3.2.0) /sw/lib/libvorbis.0.dylib (compatibility version 4.0.0, current version 4.1.0) /sw/lib/libx264.57.dylib (compatibility version 1.0.0, current version 1.0.0) /sw/lib/libxvidcore.4.dylib (compatibility version 4.0.0, current version 4.1.0) libpostproc.51.dylib: /sw/lib/libavutil.49.dylib (compatibility version 51.1.0, current version 51.1.0) /sw/lib/liba52.0.dylib (compatibility version 1.0.0, current version 1.0.0) /sw/lib/libamrnb.0.dylib (compatibility version 1.0.0, current version 1.0.0) /sw/lib/libfaac.0.dylib (compatibility version 1.0.0, current version 1.0.0) /sw/lib/libfaad.0.dylib (compatibility version 1.0.0, current version 1.0.0) /sw/lib/libmp3lame.0.dylib (compatibility version 1.0.0, current version 1.0.0) /sw/lib/libtheora.0.dylib (compatibility version 4.0.0, current version 4.4.0) /sw/lib/libogg.0.dylib (compatibility version 6.0.0, current version 6.3.0) /sw/lib/libvorbisenc.2.dylib (compatibility version 3.0.0, current version 3.2.0) /sw/lib/libvorbis.0.dylib (compatibility version 4.0.0, current version 4.1.0) /sw/lib/libx264.57.dylib (compatibility version 1.0.0, current version 1.0.0) /sw/lib/libxvidcore.4.dylib (compatibility version 4.0.0, current version 4.1.0) Patrick

2 2

pd-extended release date?
by patrick 06 Nov '09

06 Nov '09

hi hans, i would like to know if you know the release date of pd-extended. i do not need floating point precision, just an idea. pat

2 1

Re: [PD-dev] LogicalRealtime needed (was Re: [PD] packOSC TimeTag realtime vs. logicaltime)
by Winfried Ritsch 06 Nov '09

06 Nov '09

On Thursday, 5. November 2009 20:59:32 you wrote: > Hi all, > > There's no way from within Pd -- that would necessitate adding something > to the API between Pd and the audio subsystem to make a direct call to > alsa (or whatever). Since you wrote most of the alsa code, I bet > it would be easy for you to hack it in :) > Thanx, I suspected this, but wanted to get sure about this. Ok I will see for a more general solution which can be adapted to other drivers like jack or on other OSes (in a month or so). mfG winfried > Miller > > On Thu, Oct 29, 2009 at 01:58:37PM +0100, Winfried Ritsch wrote: > > Hello, > > > > Sending audio over OSC needs a accurate time-tag in sync with Audio on > > the sender so packages can be ordered, and re-sampling with the > > audio-sync on the receiver, but OSC is defined to use the universal sync > > the Internet time (realtime). > > > > Syncing computers over Internet time is already a solved problem;using > > adequat audio buffer there should be a stable solution. Since Audiotime > > is not in sync with real-time. > > > > So we need a Locgical-Realtime on the sender, that means realtime > > corrected with the offset in the audio buffer processing, which should be > > fairly excat enough. > > > > The question is now: > > > > a) How can I get the offset of the actual audio-buffer processing to > > either the ADC-time oder DAC time, the the time at the beginning or end > > of the audio- buffer in PD ? > > > > a)if not possible Should we invent for this purposes a LocalRealtime for > > each audio-buffer and how ? > > > > > > mfG > > Winfried Ritsch > > > > On Friday, 9. October 2009 05:54:25 Martin Peach wrote: > > > Wolfgang J?ger wrote: > > > > Hello, > > > > > > > > I'm using a combination of [pack~] [packOSC] -> transmission(UDP) -> > > > > [unpackOSC] and a modified version of [unpack~] to send Audio over > > > > OSC. The OSC packages are sent as Bundles so a TimeTag is generated > > > > at the sender's side. I extended the [unpackOSC] object with another > > > > outlet where I'm getting the particular TimeTag of each Bundle. > > > > In the modified version of [unpack~] I evaluate these TimeTags with > > > > regards to dropouts in the transmission. > > > > My problem is that the TimeTags are not accurate, what I ascribe to > > > > the fact, that the TimeTag in [packOSC] is generated as "real time" > > > > instead of "logical time". Using "real time" the TimeTag-"Output" is > > > > a function of the audiobuffersize (depending on the cpu load), so in > > > > my case, as the CPU-load is quite big, the values of the TimeTags are > > > > not useable for sequencing the datastream (as there are jumps in the > > > > TimeTag I always assume some packages got lost). > > > > As a workaround I established a sequence number, which is > > > > additionally transmitted in each Bundle. This is an appropiate > > > > solution, but it wouldn't be necessary if the TimeTag would be > > > > generated properly. Are my considerations conclusive? > > > > > > At the moment the timetag is calculated when the bundle is opened with > > > the [ message. If the ] message doesn't occur at the same time the > > > timetag will be wrong as the message doesn't start to get sent until > > > the bundle is closed. Then there is the delay in the OS as it schedules > > > the packet for the network and the network card deals with possible > > > collisions with other packets, etc... > > > As well, anything [packOSC] does occurs between audio blocks (and may > > > be postponed if there is too much going on), so the timing will be > > > jittery unless your packets are being composed and sent in precise sync > > > with the audio. And if they are being sent to another machine with > > > another clock of course this is never going to happen unless you can > > > sync their sound cards via SPDIF or word clock. But that's real time. > > > Because there is no way to know what the 'logical time' is outside of > > > your logical frame, just use the sequential block number as your > > > logical time. Pack a sequence number followed by a blob, possibly > > > resetting the sequence numbers when they get too big. No need for > > > bundle or timetag. > > > > > > Martin > > > > > > _______________________________________________ > > > Pd-list(a)iem.at mailing list > > > UNSUBSCRIBE and account-management -> > > > http://lists.puredata.info/listinfo/pd-list > -- -- - ao.Univ.Prof. DI Winfried Ritsch - ritsch(a)iem.at - http://iem.at/ritsch - Institut fuer Elektronische Musik und Akustik - University of Music and Dramatic Art Graz - Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171 - PGP-ID 69617A69 (see keyserver http://wwwkeys.eu.gpg.net/) --

1 0

0.42.5 pd-extended crashes
by Ivica Ico Bukvic 06 Nov '09

06 Nov '09

Hans and all, Following is not the case with either 0.41.4 or 0.43. Create a new patch->create a subpatch (e.g. [pd test]) which will immediately open upon creation->close the main patch (with or without saving)->crash. It happens consistently on my machine. However, if one closes the subpatch ([pd test]) and then closes the main patch, it does not crash. The tough part is even when runnning pd with debugging enabled and stderr flag the only output I get at crash is menuclose 2 and then segfault. Here are two examples of the relevant output: 1) (CRASHING) .x93f9c38 relocate 450x300+0+0 450x300+1+50 ; .x93f9c38 menuclose 0 ; pd watchdog ; .x93f9c38 menuclose 2; .x93f8ff8 relocate 450x300+0+0 450x300+12+127 ; Segmentation fault pd_gui: pd process exited 2) (NON-CRASHING) .xa44ee70 motion 354.0 8.0 0 ; .xa44ee70 motion 362.0 3.0 0 ; .xa44ee70 menuclose 0 ; pd watchdog ; .xa44fe88 relocate 450x300+0+0 450x300+1+50 ; .xa44fe88 menuclose 0 ; .xa44fe88 menuclose 2; It seems the first one is trying to relocate window after it has been destroyed? Something seems out of order... Ico

3 4

LogicalRealtime needed (was Re: [PD] packOSC TimeTag realtime vs. logicaltime)
by Winfried Ritsch 05 Nov '09

05 Nov '09

Hello, Sending audio over OSC needs a accurate time-tag in sync with Audio on the sender so packages can be ordered, and re-sampling with the audio-sync on the receiver, but OSC is defined to use the universal sync the Internet time (realtime). Syncing computers over Internet time is already a solved problem;using adequat audio buffer there should be a stable solution. Since Audiotime is not in sync with real-time. So we need a Locgical-Realtime on the sender, that means realtime corrected with the offset in the audio buffer processing, which should be fairly excat enough. The question is now: a) How can I get the offset of the actual audio-buffer processing to either the ADC-time oder DAC time, the the time at the beginning or end of the audio- buffer in PD ? a)if not possible Should we invent for this purposes a LocalRealtime for each audio-buffer and how ? mfG Winfried Ritsch On Friday, 9. October 2009 05:54:25 Martin Peach wrote: > Wolfgang Jäger wrote: > > Hello, > > > > I'm using a combination of [pack~] [packOSC] -> transmission(UDP) -> > > [unpackOSC] and a modified version of [unpack~] to send Audio over OSC. > > The OSC packages are sent as Bundles so a TimeTag is generated at the > > sender's side. I extended the [unpackOSC] object with another outlet > > where I'm getting the particular TimeTag of each Bundle. > > In the modified version of [unpack~] I evaluate these TimeTags with > > regards to dropouts in the transmission. > > My problem is that the TimeTags are not accurate, what I ascribe to the > > fact, that the TimeTag in [packOSC] is generated as "real time" instead > > of "logical time". Using "real time" the TimeTag-"Output" is a function > > of the audiobuffersize (depending on the cpu load), so in my case, as > > the CPU-load is quite big, the values of the TimeTags are not useable > > for sequencing the datastream (as there are jumps in the TimeTag I > > always assume some packages got lost). > > As a workaround I established a sequence number, which is additionally > > transmitted in each Bundle. This is an appropiate solution, but it > > wouldn't be necessary if the TimeTag would be generated properly. > > Are my considerations conclusive? > > At the moment the timetag is calculated when the bundle is opened with > the [ message. If the ] message doesn't occur at the same time the > timetag will be wrong as the message doesn't start to get sent until the > bundle is closed. Then there is the delay in the OS as it schedules the > packet for the network and the network card deals with possible > collisions with other packets, etc... > As well, anything [packOSC] does occurs between audio blocks (and may be > postponed if there is too much going on), so the timing will be jittery > unless your packets are being composed and sent in precise sync with the > audio. And if they are being sent to another machine with another clock > of course this is never going to happen unless you can sync their sound > cards via SPDIF or word clock. But that's real time. > Because there is no way to know what the 'logical time' is outside of > your logical frame, just use the sequential block number as your logical > time. Pack a sequence number followed by a blob, possibly resetting the > sequence numbers when they get too big. No need for bundle or timetag. > > Martin > > _______________________________________________ > Pd-list(a)iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > -- -- - ao.Univ.Prof. DI Winfried Ritsch - ritsch(a)iem.at - http://iem.at/ritsch - Institut fuer Elektronische Musik und Akustik - University of Music and Dramatic Art Graz - Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171 - PGP-ID 69617A69 (see keyserver http://wwwkeys.eu.gpg.net/) --

2 1

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 2009