Re: [PD-dev] Whose fault is this crash? (nan and inf)
On Tue, Sep 10, 2013 at 10:21 AM, Kjetil Matheussen k.s.matheus...@gmail.com wrote: ... In Pd, should objects be able to handle (i.e. not crash) when they get input values of nan and inf, or should they instead make sure that nan and inf never can be sent out of the objects, or both? It is not so much of a problem if an object puts out denormals incidentally and most classes do not provide a check, for reasons of performance. Most important is that objects can not get into a state of recycling nan / inf for a longer period of time (like in a recursive filter's state variable). For table writers it is customary to make sure they don't write any denormal, because other objects have access to the data and could make denormals to recycle. So it is the writing object that has or should have anti-denormals-protection. When using an [s~] and [r~] pair for signal connection, denormals don't go through because [s~] does the check too. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Whose fault is this crash? (nan and inf)
On Tue, Sep 10, 2013 at 11:12 AM, Kjetil Matheussen k.s.matheus...@gmail.com wrote: Perhaps expr should check for denormals as well? Math objects should be able to output denormals. Without that we could not even make test patches to find or debug denormals-issues in other classes. Two fixes then: 1. Check for denormals in expr 2. Add an isnormal call to the floating value in vd~ to avoid crashing if getting a value that fails the if (delsamps 1.1f) delsamps = 1.1f; if (delsamps limit) delsamps = limit; checks in there. NAN is unordered, the greater-than test does not handle it indeed.The PD_BIGORSMALL() macro / function as defined in m_pd.h may work well here. Some processors don't have a fast implementation of isnan() etc. On Tue, Sep 10, 2013 at 10:57 AM, katja katjavet...@gmail.com wrote: On Tue, Sep 10, 2013 at 10:21 AM, Kjetil Matheussen k.s.matheus...@gmail.com wrote: ... In Pd, should objects be able to handle (i.e. not crash) when they get input values of nan and inf, or should they instead make sure that nan and inf never can be sent out of the objects, or both? It is not so much of a problem if an object puts out denormals incidentally and most classes do not provide a check, for reasons of performance. Most important is that objects can not get into a state of recycling nan / inf for a longer period of time (like in a recursive filter's state variable). For table writers it is customary to make sure they don't write any denormal, because other objects have access to the data and could make denormals to recycle. So it is the writing object that has or should have anti-denormals-protection. When using an [s~] and [r~] pair for signal connection, denormals don't go through because [s~] does the check too. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Whose fault is this crash? (nan and inf)
On Tue, Sep 10, 2013 at 12:09 PM, Kjetil Matheussen k.s.matheus...@gmail.com wrote: On Tue, Sep 10, 2013 at 11:58 AM, katja katjavet...@gmail.com wrote: On Tue, Sep 10, 2013 at 11:12 AM, Kjetil Matheussen k.s.matheus...@gmail.com wrote: Perhaps expr should check for denormals as well? Math objects should be able to output denormals. Without that we could not even make test patches to find or debug denormals-issues in other classes. Yes, but the problem is that [expr 1/0.001] sends out inf. I meant to say denormals and non-numbers, sorry. For example, this gives 'inf' in Pd: [2( | [pow 1024] and this gives '-nan': [2( | [pow 1024] | [* 0] Since most processors don't flush denormals and non-numbers to zero by default, Pd classes have to deal with it in some selective way. If all math objects (signal objects in particular) would flush those generally undesired numbers to zero, that would make Pd slower. The compromise is to flush problematic values wherever they cause a serious problem, like recycling NaN's. In your [vd~] example the NaN seems to result in an illegal pointer value. The same issue might happen in other table reading objects with index inlets ([tabread], [tabread4~], [cyclone/poke~]). Did you try that? Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Whose fault is this crash? (nan and inf)
On Tue, Sep 10, 2013 at 2:01 PM, Kjetil Matheussen k.s.matheus...@gmail.com wrote: Since most processors don't flush denormals and non-numbers to zero by default, Pd classes have to deal with it in some selective way. If all math objects (signal objects in particular) would flush those generally undesired numbers to zero, that would make Pd slower. The compromise is to flush problematic values wherever they cause a serious problem, like recycling NaN's. In your [vd~] example the NaN seems to result in an illegal pointer value. The same issue might happen in other table reading objects with index inlets ([tabread], [tabread4~], [cyclone/poke~]). Did you try that? Thank you! That's what I wanted to know. I'll provide a more thought-through patch for vd~, and perhaps tabread4~ and poke~ as well. The trouble with vd~ was a real world example (provided by a user) that made radium (with now has pd embedded) crash. He couldn't continue working on his song, since pd patches are saved inside radium song files, and radium crashed as soon as he tried to load the song. Oops, that is a nasty case. I was just about to say: it is an open question to what extent Pd must be idiot-proof. After all, Pd can be considered a computer language, a patch can be considered a program, and the programmer has some responsibility too. Why should one send NaN as an index value or delay time to some object? Well, maybe because Pd is often used for wild experiments, like the example case illustrates. Pd should not crash on bugs in a patch I guess. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] jack dbus?
On Wed, Jun 5, 2013 at 2:16 PM, Roman Haefeli reduz...@gmail.com wrote: [...] Right. I would propose the following measurement protocol: (setup/usecase A: Pd only through ALSA) 1. In Pd using ALSA backend, run sine test signal in 'Media Test Audio and Midi...' 2. Set Pd's buffer to lowest possible value such that there are no I/O error messages or audible dropouts during 'normal Pd use', that is, while clicking (radio)buttons or switching between already loaded Pd windows. 3. For this nominal latency setting, measure actual roundtrip latency via line loopback or speaker / mic loopback, using patch latency-tester2.pd which was attached to my May 29 post in this thread. (setup/usecase B: Pd and PulseAudio through JACK/ALSA) 4. Set up a routing with Pd and PulseAudio as JACK clients. 5. In Pd, run the sine test signal. Simultaneously, play this video in a browser while routing it's sound through PulseAudio / JACK: http://www.youtube.com/watch?v=_63Cc6vPFVIfeature=youtu.be 6. For this combination, get the lowest nominal latency in Jack such that there are no I/O errors in Pd, or audible dropouts in either audio signal. JACK must be restarted for a new buffer setting to take effect. This is the most time-consuming aspect of the measurement. 7. For this routing and settings, measure the actual roundtrip latency through Pd. 8. Report nominal + measured latencies for setup A and B, together with relevant hardware and system info. My results for Panasonic CF-19 1 GHz Core2Duo, Xubuntu 12.04, built-in soundcard, no preemptive kernel: - setup/usecase A: 15 ms buffer in Pd, 18 ms measured roundtrip latency - setup/usecase B: 15 ms buffer in Pd, 23.2 ms (2*512 samples) buffer in JACK, 49.3 ms measured rountrip latency through Pd My results forIntel Core 2 Duo T8300 2.4GHz, Ubuntu 12.04 i386 (3.2.0-44-lowlatency-pae) HDA Intel - - usecase A: blocksize 128 in Pd, measured roundtrip 10ms - usecase B: 5.9ms (2frames, 128fr/period), measured roundtrip 14.9ms HDSP RPM with cardbus - - usecase A: blocksize 128 in Pd, measured roundtrip 10ms - usecase B: 5.9ms (2frames, 128fr/period), measured roundtrip 14.9ms Some notes: Whether pulse server was connected to jackd didn't have any influence at all on the best working jackd settings. Either I could start jackd or not. When jackd was running, I didn't get any drop-outs, with or without pulse connected as client. Just to make sure: did you also play the internet video, and get uncompromised quality for both audio signals with those settings? The buffer(ms) setting in Pd doesn't have any influence on the effective latency on my box, with both cards. That is why I reported only the blocksize, which seems the only parameter to have any effect on latency. With Pd connected to jackd, even blocksize doesn't change anything. This is weird, eh? I guess the Media Audio Settings Delay(msec) sets Pd's buffer size (rounded or truncated to an integer number of blocks), when it's using ALSA. Anyway this setting normally influences measured latency in a linear fashion. When Pd goes through JACK instead, it seems that Pd's buffer size setting is irrelevant because JACK's buffer is forwarded to Pd. Unfortunately, my expensive soundcard does not perform any better than the built-in, regarding latency. It seems this is a regression in the alsa from my Ubuntu version. I remember I was able to set a lower value for frames/period, 32 and 64 have been also working in previous versions of Ubuntu, with the same laptop and the same HDSP card. Nice latency measurement patch, btw. There is one smallish issue with it. When testing low latency setups, the latency patch itself causes drop-outs because of the 1-1 loop executed in zero logical time. That is not elegant indeed, even though the loop comes after the data is recorded. I could not find an alternative for the loop, using vanilla objects. If it could be broken in parts, your [nbuntil] solution could help. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] jack dbus?
On Tue, Jun 4, 2013 at 3:08 AM, Jonathan Wilkes jancs...@yahoo.com wrote: [...] Sorry, I'm talking about a few things at once. One would be to test Pd by itself with ALSA backend vs. Pd by itself with JACK backend. That would provide some data re: the page you linked to about latency. (My suggestion about Pd-JACK + VLC-with-jack-backend-JACK was meant to cover that case and also compare to Pd-JACK +Pulse-JACK, but as you say we can delve into that later.) The other is: what's a recommendable setup for using Pd in GNU/Linux with acceptable/controllable latency while still behaving with the rest of the system. Your Pd/Pulse/JACK measurements help to address that. You're right, JACK's latency 'discrepancy' should be investigated separately. On my system I observe this behaviour: - Pd with ALSA: measured latency is [Pd-nominal-latency + 3] milliseconds - Pd through JACK with ALSA: measured latency is [JACK-nominal-latency * 2 + 3] ms - Pd + PulseAudio through JACK with ALSA: [JACK-nominal-latency * 2 + 3] ms Here it seems that JACK's latency is double it's buffer size, no matter if PulseAudio is connected or not. But wait, it's logical! The loopback signal goes through JACK twice. Buffering is applied at capture and at playback, and by default both buffers have size [frames * periods]. Check with command jack_lsp -l. Optionally, extra input and/or output latency can be added, however this does not reflect in my measurements. Apart from the effect that JACK's latency may be different from what you'd expect, there is the effect that Pd + internet video requires more buffering than Pd only. It's a pity that JACK's bufsize can not be set in runtime. It seems reasonable to expect and accept increased latency if you want to play internet video's etc. together with Pd. Switching between setups would be scriptable to make it easier (also see http://gareus.org/wiki/qjackctl_dbus). But for the moment, I even get stuck many times when switching 'by hand'. Apparently, the order of operations is very critical. If it goes wrong, getting the d-bus error from JACK I haven't found another option than kill the jackdbus process and try again. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] jack dbus?
On Mon, Jun 3, 2013 at 9:04 AM, IOhannes m zmoelnig zmoel...@iem.at wrote: On 2013-06-02 08:51, Jonathan Wilkes wrote: Of course these are just the latencies in the settings-- I haven't done the actual measurements yet. it would be interesting to have actual measurements. everything else is wild speculation. Right. I would propose the following measurement protocol: (setup/usecase A: Pd only through ALSA) 1. In Pd using ALSA backend, run sine test signal in 'Media Test Audio and Midi...' 2. Set Pd's buffer to lowest possible value such that there are no I/O error messages or audible dropouts during 'normal Pd use', that is, while clicking (radio)buttons or switching between already loaded Pd windows. 3. For this nominal latency setting, measure actual roundtrip latency via line loopback or speaker / mic loopback, using patch latency-tester2.pd which was attached to my May 29 post in this thread. (setup/usecase B: Pd and PulseAudio through JACK/ALSA) 4. Set up a routing with Pd and PulseAudio as JACK clients. 5. In Pd, run the sine test signal. Simultaneously, play this video in a browser while routing it's sound through PulseAudio / JACK: http://www.youtube.com/watch?v=_63Cc6vPFVIfeature=youtu.be 6. For this combination, get the lowest nominal latency in Jack such that there are no I/O errors in Pd, or audible dropouts in either audio signal. JACK must be restarted for a new buffer setting to take effect. This is the most time-consuming aspect of the measurement. 7. For this routing and settings, measure the actual roundtrip latency through Pd. 8. Report nominal + measured latencies for setup A and B, together with relevant hardware and system info. My results for Panasonic CF-19 1 GHz Core2Duo, Xubuntu 12.04, built-in soundcard, no preemptive kernel: - setup/usecase A: 15 ms buffer in Pd, 18 ms measured roundtrip latency - setup/usecase B: 15 ms buffer in Pd, 23.2 ms (2*512 samples) buffer in JACK, 49.3 ms measured rountrip latency through Pd I would suggest we do Pd+PulseAudio-through-JACK discussion on pd-list if we continue this. The how-to and details of it are not a dev topic, though the consideration of writing direct PulseAudio support for Pd is. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] jack dbus?
On Mon, Jun 3, 2013 at 9:25 PM, Jonathan Wilkes jancs...@yahoo.com wrote: [...] Don't we want to compare straight to ALSA to pd to JACK to ALSA, just with Pd running? Having Pulse in the mix is good to measure as well, but I'd like to get a handle on the JACK adds no latency statement and comparing additionally with just Pd running through JACK will simplify that. Also, it may be helpful to add: Pd through JACK, VLC using JACK backend through Jack and compare it to the one using PulseAudio through JACK. If I'm not mistaken, it was your original idea to test a setup where all audio sources can be played together with Pd, i.e. Pd + PulseAudio + JACK, and compare with Pd's current default routing (plain ALSA). So that's what I did. I'm now eager to know results from others before further delving into it. Another question: what are you using to play the Youtube video? I know the proprietary Flash plugin caused problems with Pulse at one point. Flash plugin indeed (no problem with Pulse on Xubuntu). Should we better find an HTML5 stream for the test? [...] Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] jack dbus?
On Wed, May 29, 2013 at 7:32 PM, Jonathan Wilkes jancs...@yahoo.com wrote: There's no other combination of frames/period and period/buffer you can use to get ca. 17-20ms latency without dropouts? Not on the hardware I'm using. Any ideas on what is causing the discrepancy? It has to be either a bug in JACK/Pd/OS, or some configuration detail (e.g., JACK isn't in realtime mode or something more subtle). I wouldn't think it has to do with your specific audio device as JACK uses ALSA as a backend. I have a hard time believing every Ardour user/dev would be putting up with a latency that high when simply going straight through ALSA would be that much better. Note that the buffer settings I mentioned were for the routing under discussion: Pd and Pulseaudio through JACK, and playing a Youtube video together with Pd audio. This is more demanding than just Pd, so I'm not surprised that it can't be done with shorter JACK buffer. It's already shorter than QjackCtl's default (2*1024). I don't think there's something wrong with my audio setup (but the laptop specs are modest with 1 GHz core2duo, no preemptive kernel). Jackaudio.org's 'no-latency' statement to which you referred is weird. This article is more practical: http://apps.linuxaudio.org/wiki/jack_latency_tests I'm curious what measured roundtrip latency through Pd you can get on your system when playing an internet video simultaneously, Jonathan? [...] So I suppose if a large portion of (GNU/Linux) Pd users don't need to get low latency at all, then it's beneficial to have a default audio backend that works like everything else in their distro. However, if getting low latency is a common goal then it's very important to lay out some instructions for how best to set up JACK to get reliable low-latency performance. Of course both can be done at the same time if there's enough interest. (Personally, I want to give the latter priority since it's way harder to get reliable low-latency setup than it is to get Pd to produce sound in the first place.) Even if someone develops pulseaudio support for Pd today, it will take a while before it's in a release. Testing and documenting other mixing setups is a good idea anyway. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] jack dbus?
On Tue, May 28, 2013 at 7:08 AM, Jonathan Wilkes jancs...@yahoo.com wrote: [...] So, I'm curious about this: http://trac.jackaudio.org/wiki/JackDbusPackaging Specifically the D-bus only JACK route. _If_ it works reliably (and of course that's a big if) then it gives the best of both worlds: all cases 1,2, and 3 above are covered by the JACK server automatically starting and Pulse getting out of the way for it. Moreover, Pulse clients get routed to JACK with what I take are sane defaults. So, if you have Pd running through JACK with this setup and then you open up a youtube video in Firefox, Pulse will automagically make a connection to JACK for it and (I'm guessing) hook it up to the output. Any thoughts on this? I'm thinking if we could build up a body of knowledge on this approach it would be the easiest way to get worry-free audio setups with GNU/Linux distros that wouldn't give new users headaches. Plus it would scale up: if they learn and care about insanely low latencies, they are already using JACK so it's just a matter of firing up qjackctl or whatever and configuring the audio server they've been using. Anyway I'll do some testing with it on Debian Wheezy over the next month. If anyone wants to try on other distros that'd be helpful (Linux Mint, Ubuntu, etc.) I checked it on Xubuntu: running Pulseaudio as an audio submixer through JACK . In Pulseaudio's mixer GUI (which is the default mixer in Xubuntu's panel), JACK can be selected as destination for an application's audio output, but only when the application is indeed delivering audio. For example, when a video is playing in Firefox, the audio interface option boxes appear. Setting up the connections manually is time-consuming. But, since JACK adds some latency to Pd, I would not use it as default (autostart) setup. The lowest practical roundtrip latency through Pd I could get in the JACK-with-Pulseaudio setup was measured 50 ms, 32 ms more than directly through ALSA. Is there not another way to play sound files or tutorial video's together with Pd? I found one nice alternative: make VLC JACK-aware and use it to play media files and network streams through JACK. To prepare the setup: - install vlc package (multimedia player and streamer) if it's not already installed - install vlc-plugin-jack package - in VLC preferences, set audio output to JACK A Youtube video can be played in VLC via menu Media Open Network Stream. It should be possible for other streams as well but I still have to find out how to do Vimeo or Soundcloud. The VLC/JACK route would not be most convenient to watch internet video clips on a regular basis. However for incidental use, the advantage is that VLC connection is quickly made in JACK. Katja Best, Jonathan ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] jack dbus?
On Wed, May 29, 2013 at 5:00 PM, Jonathan Wilkes jancs...@yahoo.com wrote: I checked it on Xubuntu: running Pulseaudio as an audio submixer through JACK . In Pulseaudio's mixer GUI (which is the default mixer in Xubuntu's panel), JACK can be selected as destination for an application's audio output, but only when the application is indeed delivering audio. For example, when a video is playing in Firefox, the audio interface option boxes appear. So when you pause the video does the option box go away? The controls for Firefox disappear when Firefox is closed, but also when going to an URL without media stream. It seems that the quickest way to make it work is: first make sure that pulsaudio does not run (and is not autospawned), then start jackdbus via QjackCtl, then start pulseaudio. This way, pulsaudio sink and source are automatically connected in JACK, and JACK is automatically selected as the sink for Firefox in Pulseaudio's mixer (I don't get an option box any more). Setting up the connections manually is time-consuming. But, since JACK adds some latency to Pd, I would not use it as default (autostart) setup. The lowest practical roundtrip latency through Pd I could get in the JACK-with-Pulseaudio setup was measured 50 ms, 32 ms more than directly through ALSA. Hm... http://jackaudio.org/no_extra_latency I'm talking about running PulseAudio on top of JACK and not the other way around. Is that what you're doing? I know only one way at the moment: routing Pulseaudio through JACK, equivalent to how Pd is routed through JACK. If this is called 'Pulseaudio on top of JACK', then 'yes'. The extra latency is because I need to set 2 periods of 512 samples (23 ms) for JACK's buffering to get audio without dropouts in this setup. In Pd I have it fixed at 15 ms. In practice there are more causes for latency, so I measure roundtrip latency in Pd with a sample-precise routine (see attached patch 'latency-tester2.pd'). Pd's 15 nominal ms is in practice 18 ms when routed directly via ALSA. Via the JACK + Pulseaudio setup it is a total of 50 ms in practice. By the way this does of course not say anything about latency in Pulseaudio. Maybe there is a way to test that with a 'pulsified' application, for example Audacity. Katja latency-tester2.pd Description: Binary data ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] jack dbus?
On Wed, May 29, 2013 at 7:32 PM, Jonathan Wilkes jancs...@yahoo.com wrote: There's no other combination of frames/period and period/buffer you can use to get ca. 17-20ms latency without dropouts? Not on the hardware I'm using. I guess the absolute latency could be lower on faster hardware, but my point was to compare the different routings while keeping other conditions equal. By the way this does of course not say anything about latency in Pulseaudio. Maybe there is a way to test that with a 'pulsified' application, for example Audacity. That would be interesting to see. By way of test, in Audacity I've set recording and playback device to pulse, and recorded a click at time zero from track 1 to track 2 via loopback. Buffer size and latency compensation were both set to 100 ms so they should compensate each other. The recorded impulse appears at around 0.058 seconds. If I've done it right, this would point to 58 ms total roundtrip latency. In a real time application like Pd you could not compensate for latency, so Pd's own buffer length should probably be added to the figure, making some 70 ms as a minimum. It seems to me that direct PulseAudio support for Pd would be interesting for ease of use, especially important for Pd/Linux beginners. Long latency is annoying, but at least less confusing than having no audio at all from some applications. However, it should be noted that Pulseaudio's mixer does not by definition provide controls for all (parts of) hardware devices. In some cases, it silently switches an input or output, without presenting the corresponding button on the mixer GUI. In such a case, only an ALSA mixer gives control over the hardware, and pulseaudio must be killed to return control to the ALSA mixer. So, Pulseaudio can make things very confusing too. But that goes beyond the influence of Pd. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Mac Os now requiring Apple signatures on all SW !?
About OSX 10.8 Mountain Lion I've read some time ago that it would run / install apps from certified Apple devs only, unless the user disables that level of security, and then it would run any app without such restriction (which is of course not recommended). At the time I read about that, I was considering upgrading from OSX 10.5, but the concept of 'Apple certified developer' made me think twice. Eventually, it made me turn towards Linux for good. Still I feel that Pd, externals and patches should be supported for as many platforms possible, as is tradition. I can understand why Apple wants to raise their standard for trusted code. In Linux world too, there's screening before one gains write access to trusted repositories, which is obviously beneficial for quality and security. But in Apple's case, selection rationale and criteria will not be open to discussion, or even fully knowledgeable. Therefore, being 'Apple certified developer' is more like being a loyal employee than an independent software developer. Frankly, I feel no appeal at all. Hopefully there's a way around. Katja On 5/10/13, Jonathan Wilkes jancs...@yahoo.com wrote: - Original Message - From: Miller Puckette m...@ucsd.edu To: pd-dev@iem.at Cc: Sent: Friday, May 10, 2013 12:41 PM Subject: [PD-dev] Mac Os now requiring Apple signatures on all SW !? T o Pd devs - I heard from a student that the neweset Mac Os (10.8? not sure - perhaps we can just call it 'Cheshire Cat') won't run binaries of any sort that haven't been signed by Apple - and that to get Apple to sign your app you have to register as a developer ($100/year) and still risk getting denounced as non-Apple-approved. If this is really the case it puts all of us in a bind - for example to publish a piece of music that relies on a custom extern you'd have to pay out the $100 in perpetuity to keep the extern signed. Maybe this is overblown but if it's true it puts Pd devs in a bind - I think we're obliged to try to suppport Pd on Apple (so as not to undercut current Pd users who are on Mac) but to play along with Apple would be to participate in what is ultimately a scheme to wrest control away from computer users everywhere. I'd welcom others' views on this, especially if someome can tell me this is a false alarm :) I haven't read a single article or new story on anything resembling this. Such a move would make the entire Apple ecosystem incompatible with ALL GPL v3 software. I suppose such a move isn't outside of the realm of possibility, but if Apple did go down that road you can bet it will effect more than just Pd-extended/Pd-l2ork. So either a) its FUD, or b) we would throw our weight behind whatever large-scale organizing effort manifests itself (probably coming from the FSF) to defeat such a move. Either way it should not affect a single line of Pd code nor the development process. -Jonathan Miller ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Mac Os now requiring Apple signatures on all SW !?
Correction, current terminology is 'identified developer' (not 'certified'). Here's Apple's how to handle apps from unidentified devs on OSX 10.8: http://support.apple.com/kb/PH11436 Katja On 5/10/13, katja katjavet...@gmail.com wrote: About OSX 10.8 Mountain Lion I've read some time ago that it would run / install apps from certified Apple devs only, unless the user disables that level of security, and then it would run any app without such restriction (which is of course not recommended). At the time I read about that, I was considering upgrading from OSX 10.5, but the concept of 'Apple certified developer' made me think twice. Eventually, it made me turn towards Linux for good. Still I feel that Pd, externals and patches should be supported for as many platforms possible, as is tradition. I can understand why Apple wants to raise their standard for trusted code. In Linux world too, there's screening before one gains write access to trusted repositories, which is obviously beneficial for quality and security. But in Apple's case, selection rationale and criteria will not be open to discussion, or even fully knowledgeable. Therefore, being 'Apple certified developer' is more like being a loyal employee than an independent software developer. Frankly, I feel no appeal at all. Hopefully there's a way around. Katja On 5/10/13, Jonathan Wilkes jancs...@yahoo.com wrote: - Original Message - From: Miller Puckette m...@ucsd.edu To: pd-dev@iem.at Cc: Sent: Friday, May 10, 2013 12:41 PM Subject: [PD-dev] Mac Os now requiring Apple signatures on all SW !? T o Pd devs - I heard from a student that the neweset Mac Os (10.8? not sure - perhaps we can just call it 'Cheshire Cat') won't run binaries of any sort that haven't been signed by Apple - and that to get Apple to sign your app you have to register as a developer ($100/year) and still risk getting denounced as non-Apple-approved. If this is really the case it puts all of us in a bind - for example to publish a piece of music that relies on a custom extern you'd have to pay out the $100 in perpetuity to keep the extern signed. Maybe this is overblown but if it's true it puts Pd devs in a bind - I think we're obliged to try to suppport Pd on Apple (so as not to undercut current Pd users who are on Mac) but to play along with Apple would be to participate in what is ultimately a scheme to wrest control away from computer users everywhere. I'd welcom others' views on this, especially if someome can tell me this is a false alarm :) I haven't read a single article or new story on anything resembling this. Such a move would make the entire Apple ecosystem incompatible with ALL GPL v3 software. I suppose such a move isn't outside of the realm of possibility, but if Apple did go down that road you can bet it will effect more than just Pd-extended/Pd-l2ork. So either a) its FUD, or b) we would throw our weight behind whatever large-scale organizing effort manifests itself (probably coming from the FSF) to defeat such a move. Either way it should not affect a single line of Pd code nor the development process. -Jonathan Miller ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Rewriting a unified phasor / metro object for reading tables
On Wed, May 8, 2013 at 11:00 PM, Ed Kelly morph_2...@yahoo.co.uk wrote: ... 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... ... A [phasor~] ramp should start with the remainder after wrapping, which is non-zero in most cases. For pd-double I had to rewrite [phasor~], and it turned out that an implementation with branching is more efficient on current Intel processors. ARM processors do branch predication, it could be efficient as well. You could try the code from here and put message triggers in the branches: https://github.com/pd-projects/pd-double/blob/master/src/d_osc.c Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] no sound from bsaylor/svf~ and cyclone/svf~
On Fri, Dec 21, 2012 at 11:07 PM, Hans-Christoph Steiner h...@at.or.at wrote: Turns out adding -fno-strict-aliasing after -ftree-vectorize does nothing, so the no sound part is indeed caused by bsaylor/svf~ being compiled with -fstrict-aliasing. Indeed bsaylor/svf~ works again when type punning is removed (used PD_BIGORSMALL instead to avoid subnormals). Patch file submitted to patch tracker. Who is maintaining Ben Saylor's stuff by the way? His name is on this maintainer's list: http://puredata.info/dev/roles but the list is very much outdated. There is even the name of someone who isn't alive anymore. I'm sure I've seen another maintainer's list somewhere, but can't find it now. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] no sound from bsaylor/svf~ and cyclone/svf~
Have to eat my words. Nothing wrong with cyclone/svf~, it's just that Pd-E would erroneously load the help patch of bsaylor/svf~ after a click on cyclone/svf~ in the help browser (after bsaylor/svf~ was loaded once). So the problem is with bsaylor/svf~, that's probably an easy fix. What about the help browser? It loads the wrong help patch because of a namespace clash. Will Pd never reload an external with same symbol but different path? Katja On Fri, Dec 21, 2012 at 10:30 PM, katja katjavet...@gmail.com wrote: So I was going to replace type punning flush-to-zero in bsaylor/svf~ with something else, but first wanted to check how it behaves in Pd-E 0.42 and in latest 0.43 autobuild. As it happens, it gives no output sound at all in latest autobuild. It's compiled with fno-strict-aliasing. By coincidence it occurred to me to check cyclone /svf~. No sound either! In dutch we say 'alsof de duvel ermee speelt'. The issues may be unrelated. cyclone/svf~ has four inlets and one outlet now, while it used to have three inlets and four outlets. This is with Pd-0.43.4-extended-20121221.app for OSX 10.5 i386 (but very unlikely that cyclone/svf~ has different number of outlets on other platforms). Weather forecasts are unfavorable for this weekend and I may spend some time on these issues. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] no sound from bsaylor/svf~ and cyclone/svf~
On Fri, Dec 21, 2012 at 11:07 PM, Hans-Christoph Steiner h...@at.or.at wrote: I get the right help patch in all cases I could think of using Pd-extended 0.43.4 2012-12-19, see attached: Ah I see. I also get the right help patch but with the wrong svf~! Try this: start Pd, first load bsaylor/svf~, then the help patch from cyclone/svf~. You get cyclone's patch but with bsaylors' svf~ (with four inlets and one outlet), no? And the other way round is also true. This is what confused me. But probably this makes sense (though it is not the desired behaviour in all cases): once a symbol is loaded, Pd will not reload it. Pd does not remember the path where a symbol was loaded from, or does it? Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] dirty flag for array?
Hello, I'm currently working on a port of a MaxMsp class which operates on a buffer and sets a dirty flag when something's changed. Does Pd have a dirty flag for a t_garray buffer, and API methods for setting and getting the value? From the archives I learn that Thomas Grill had worked on that in the past but I am not able to find such a thing in m_pd.h. I just want to be sure, before I erase the corresponding C lines. Thanks, Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] help compiling pd 0.43 on Windows 7
On Tue, Nov 29, 2011 at 5:37 PM, Hans-Christoph Steiner h...@at.or.at wrote: The new build system doesn't need the makefile.dependencies, and that has always been a bit of a mystery. Ah, so I'm not the only one being puzzled, happy you say so. I'm intensely frustrated after spending five days to get things working with mingw. Todays it's like this: when compiling pd-double with makefile.mingw, makefile.dependencies does actually get produced, but then comes 'no rule to make am--refresh. Stop.' when entering extra/. No clue how to solve that again. Writing or fixing C code is easy pie compared to handling the GNU build tools. It is a miracle how you guys manage to produce all those pd-extended builds. Well I should probably read the f. manual, it's too complex to hack ur way through it. Another pit stop on the way to pd-double. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] help compiling pd 0.43 on Windows 7
On Tue, Nov 29, 2011 at 7:02 PM, IOhannes m zmoelnig zmoel...@iem.at wrote: you shall decide to either use makefile.mingw or the new autotools system. you shall never mix the two. especially, you shall not run ./autogen.sh and then try to compile using makefile.mingw thus: remove all traces from the autotools build system (namely any generated files, like GNUmakefile) Ha. That is a decisive remark. So the generated makefiles were confusing the process from makefile.mingw. Back-and-forth jumping between the methods probably induced some irreproducible successes as well. Now starting with two fresh copies of the sources, one for each build system. Still an error with makefile.mingw, (no rule to make the 'extra's') but that should be solvable. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] help compiling pd 0.43 on Windows 7
Gave it another try this weekend: building vanilla pd on windows. Though I once had a pd build using makefile.mingw, this must have been a stroke of luck, a fortunate sequence of operations which I don't know how to reproduce. Instead, I now used the 'new build system' with a few adaptations. These adaptations were derived from a patch file for pd-extended by Patrice Colet and Hans Christoph Steiner. The patch (the one for vanilla, attached, beware that it has windows style line endings) takes care of the following: - definition 'cc=g++' is no longer applied, and some errors triggered by c files in the port audio section now become warnings - pd-watchdog is disabled for Mingw - pd~ is disabled for windows The build was done with Mingw. Even with the patched build system it is still a fair pain i.t.a. to build vanilla pd on windows, specially when compared to building on Linux. A lot of .dll's and header files must be collected and copied into the appropriate directories of the build tree. In order to download the asio sdk one is supposed to fill a form with all personal info's when subscribing as Steinberg third party developer. Some .dll's and headers can be copied from a vanilla Pd windows binary distribution. The following .dll's must be copied from the Mingw binaries into Pd's bin/ directory, they're not in Pd binary distributions: - libgcc_s_dw2-1.dll - libstdc++-6.dll - libpthread-2.dll I've not tested the build other than with the audio and midi test, as I'm now heading for a pd-double build for windows, and for sure there's something to fix in the audio interface files before pd-double will work. To be continued. Katja new-build-system-vanilla-Mingw.patch Description: Binary data ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] help compiling pd 0.43 on Windows 7
On Mon, Nov 28, 2011 at 6:37 PM, Hans-Christoph Steiner h...@at.or.at wrote: I think Miller doesn't use MinGW, so building vanilla on Windows is probably easiest using MSVC like he does. Pd-extended builds nightly (when the server is up) using the pd/src/makefile.mingw. Oow, I was in the assumption that 'new build system' was the preferred way for autobuilds. Well then I have to make it work with makefile.mingw. One purpose of my pathetic efforts is to get pd-double built this way so we can have pd-double-extended test builds for windows one day. It's so weird that makefile.mingw doesn't create makefile.dependencies, it only re-creates an empty makefile.dependencies when performing a clean. So I have to fool it with a dummy. Is there a better way to get this working? On OSX by the way, makefile.dependencies is always created with 'old build system', but it's empty sometimes, and filled with paths other times. In both cases the build will work. What is this mysterious behaviour? Makefile.mingw for vanilla seems to be outdated, some elements from makefile.mingw for pd-extended have to be incorporated to make it work. When s_utf8.c is added to SRC, and -lpthreadGC2 is replaced by -lpthread in LIBS, a build is at least produced. Is -lpthread compatible with the windows autobuild configuration? Is there a way to produce a 'local build' somehow with makefile.mingw? Like 'old build system' can do it without install, and 'new build system' can do it with option --prefix for configure? Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] help compiling pd 0.43 on Windows 7
On Tue, Nov 29, 2011 at 12:57 AM, Hans-Christoph Steiner h...@at.or.at wrote: The new build system is almost ready for nightly Windows builds, but not quite. So the Pd-extended nightly builds still use pd/src/makefile.mingw. If you want to work on this, then I think you'll need to port all of the new build system stuff from pd-extended to pd-double, where it works on Windows/MinGW. Otherwise, you'll just be recreating that work. Think I've got the essential bits ported by now, for both methods. Only thing is, I need to manually create makefile.dependencies before makefile.mingw can do it's work. That is not ok. A diff between pure-data / pd-extended makefile.mingw doesn't point to a solution. Is there some other element involved? Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] unittests and template Makefile merging
On Thu, Nov 17, 2011 at 5:34 AM, Hans-Christoph Steiner h...@at.or.at wrote: I incorporated your unittests changes into the template Makefile, that should make it easier to update the Makefiles of any lib you are adding unittests too. Thanks. I'd already hacked a simple patch file from the diff between old and new smlib Makefile, to patch the non-user section of any template-style Makefile. This seems to work well but I don't know where to store that patch file in svn. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] a true Pd-double autobuild finally available for testing
Finally there is a first true Pd-double nightly build available for testing, almost one month after the first announcement. It is an OSX i386 build. Other builds will hopefully follow soon. http://autobuild.puredata.info/auto-build/2011-11-17/ Beware! This pre-pre-alpha Pd-double-extended is probably the buggiest Pd you've ever seen. The largest part of it still has to be tested and precision-fixed. Precision-issues can in some cases produce ridiculous output values, in the range of billions or trillions. Use an analog volume control when testing Pd-double-extended, and set it _low_ to start with. parts which are so far precision-fixed and tested on OSX and Linux: most of pd-double core externals/extra (except [pd~]) externals/creb externals/smlib externals/vbap precision-fix priorities: - making pd-double core work for Windows - find and fix pointer typecast cases resulting in dangerously high output values - fix cw_binaural to compile and work in double precision so it can be included in the LIB_TARGETS again long term: - make unit tests for all classes in all libs - fix all precision issues - develop a method to prevent cross-precision lib-loads Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] externals implementing PD_FLOAT_PRECISION can't be compiled against pure-data, libpd, pd-l2ork etc
We now have PD_FLOAT_PRECISION in the Pd-extended API (even though it's value is still fixed at 32) and in Pd-double. This macro is sometimes needed for conditional compilation when making external libs ready for double precision. For example, to call sf_read_float() or sf_read_double() in libsndfile, or in case of a type punning trick which must be defined according to data type. Libs which use PD_FLOAT_PRECISION for such reason, are no longer compilable against pure-data, libpd, pd-l2ork and other types of pd. This is now the case for creb and smlib, for which I committed double-ready changes this week. Before I proceed committing to other libs, this issue should discussed with authors and maintainers of pure-data, it's forks, and external libraries. Historically, external libs have always been compilable against Pd flavours other than Pd-extended, no? It would be an awkward experience for anyone unsuspectingly copying a lib's latest revision from pure-data.svn and find it's no longer compatible with Pd other than Pd-extended and Pd-double! Technically, the solution is simple: a line '#define PD_FLOAT_PRECISION 32' in the API's would restore compatibility, when t_float etc. are still typedef'ed as float. It is not so elegant we have to bother many people with our double precision efforts, but it's impossible to develop this in isolation. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] externals implementing PD_FLOAT_PRECISION can't be compiled against pure-data, libpd, pd-l2ork etc
To answer my own mail, let's just do this whenever using PD_FLOAT_PRECISION: #ifndef PD_FLOAT_PRECISION #define PD_FLOAT_PRECISION 32 #endif to make sure code remains compilable against all sorts of Pd. When PD_FLOAT_PRECISION is not defined, it is safe to assume t_float etc are float. Katja On Sat, Nov 12, 2011 at 3:30 PM, katja katjavet...@gmail.com wrote: We now have PD_FLOAT_PRECISION in the Pd-extended API (even though it's value is still fixed at 32) and in Pd-double. This macro is sometimes needed for conditional compilation when making external libs ready for double precision. For example, to call sf_read_float() or sf_read_double() in libsndfile, or in case of a type punning trick which must be defined according to data type. Libs which use PD_FLOAT_PRECISION for such reason, are no longer compilable against pure-data, libpd, pd-l2ork and other types of pd. This is now the case for creb and smlib, for which I committed double-ready changes this week. Before I proceed committing to other libs, this issue should discussed with authors and maintainers of pure-data, it's forks, and external libraries. Historically, external libs have always been compilable against Pd flavours other than Pd-extended, no? It would be an awkward experience for anyone unsuspectingly copying a lib's latest revision from pure-data.svn and find it's no longer compatible with Pd other than Pd-extended and Pd-double! Technically, the solution is simple: a line '#define PD_FLOAT_PRECISION 32' in the API's would restore compatibility, when t_float etc. are still typedef'ed as float. It is not so elegant we have to bother many people with our double precision efforts, but it's impossible to develop this in isolation. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] getting double fixes into extra/
On Thu, Nov 10, 2011 at 4:26 PM, Hans-Christoph Steiner h...@at.or.at wrote: Even better would be to fix the new build system. One of the reasons I removed extra/ from Pd-extended and made it a separate library is because of the brokenness of the build system. For the moment, I abuse the Pd-extended package build system to produce a properly working vanilla Pd-double. The target 'darwin_app_core' seems to build pd-extended/extra/, or in my case pd-double/extra/. Not pd-svn/externals/extra/, I know because this code does not yet compile in double precision. O yeah, there's one thing to remember when hacking this way: the script changes the PD_TEST_VERSION definition in m_pd.h. Via this build, using the regular helpfiles, I've checked that all 'extra' objects appear to work normally in double precision now. A single precision build was checked earlier. I've pushed the latest changes to the pd-double github. Since all changes to the extra's are fairly trivial (float to t_float or t_sample mostly), I don't think that more detailed tests are needed here for single precision case. For double precision, the [expr] family should be tested more thoroughly someday, but this need not prevent us from submitting a patch for pure-data.git now. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] getting double fixes into extra/
On Wed, Nov 9, 2011 at 4:58 AM, Hans-Christoph Steiner h...@at.or.at wrote: Ah these typedefs are nonsense indeed, t_float and t_floatarg are defined in msp's zdsp.h as well, at least since Max/Msp5, earlier versions I don't know. Ah I see, they are for Max/MSP only? I didn't notice that before. So I guess the thing to do would be for you do make adjustments in the pd-double.git, then we can rebase into a patch for just extra and submit it for Miller. I think these changes are worth getting into pure-data.git now since in 0.42 Miller already went thru the core source code to make sure all of the t_float and t_sample types were used where they made sense. Checked it once more, t_float and t_sample are defined in zdsp.h at least in Max/Msp version 4.6 and 5 (not t_floatarg however, a float argument is always a double in Max/Msp). Since zdsp.h is included in all cases, I should leave t_float and t_sample typedefs out indeed. I'll do the adjustments in pd-double.git. Remarkably, t_float is not defined in the max-includes (for non-signal classes) in Max/Msp. So far I have just turned float into t_float. Only when t_sample and t_float are used consistently throughout all Pd(-extended) code, it would be possible to define them differently. Meaning, there must never be an implicit or explicit t_samplet_float pointer cast. To check/implement this is more work than just making double-ready. Should we do it nonetheless, or leave this for a next clean-up? Or maybe I should do it for pure-data's extra's now, before submitting a patch for pure-data.git? Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] getting double fixes into extra/
On Wed, Nov 9, 2011 at 5:51 PM, Hans-Christoph Steiner h...@at.or.at wrote: So far I have just turned float into t_float. Only when t_sample and t_float are used consistently throughout all Pd(-extended) code, it would be possible to define them differently. Meaning, there must never be an implicit or explicit t_samplet_float pointer cast. To check/implement this is more work than just making double-ready. Should we do it nonetheless, or leave this for a next clean-up? Or maybe I should do it for pure-data's extra's now, before submitting a patch for pure-data.git? I think we should submit the current changes now since they will get things building at double-precision at least. Then further fixes can be submitted later. Ok, now done like this: whenever it's straightforward to implement t_sample, I do so, but in complicated cases where it's too time consuming I leave it for later. When doing a last check on the 'extra' objects, I ran into a problem with the install as done by the new build system. (Though Pd core works without install, the extra's do not, so a regular or local install must be done to test the objects.) The [pd~] object can not be loaded, it says: pd~: can't stat /usr/local/lib/pd/pd This seems unrelated to the double-ready code, because pure-data.git shows exactly the same issue when built with the new build system. Also, these builds both show: soundfiler_read: ../doc/sound/voice.wav: No such file or directory while the file is certainly located in /usr/local/doc/sound/ and pd is running from /usr/local/bin/. With local build, same problem. Using the old build system for a local build, these issues did never appear. Neither with packaged builds. All stuff in 'extra' is checked now, apart from [pd~]. So I'd suggest: - I push the changes to pd-double - could the old build system be brought back into pd-double, for convenience? - only when [pd~] is verified to work, let's submit patch for pure-data.git Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] nightly builds broken
Today's autobuilds are broken again, still due to my double-precision commit! Sorry sorry. The real cause lies here: There is a small but crucial difference in the API between Pd-extended and Pd-double. In Pd-extended, float precision is defined with PD_FLOATSIZE and in Pd-double it is PD_FLOATPRECISION. This must be resolved before we can continue developing the external libs against Pd-double. In retrospect, it seems rather illogical to have these different macro names, so you may wonder how this came about. When I started rewriting Pd core code last summer to make it ready for double precision, there was only PD_FLOATTYPE which could be defined 'float' or 'double'. I soon found that the preprocessor could not do string comparison, and a numeric definition was needed to do conditional checks at compile time. I opted for PD_FLOATPRECISION, to be set at 32 or 64 for the number of bits. Around the same time, IOhannes introduced a macro PD_FLOATSIZE (to be set at 32 or 64) in Pd-extended when he rewrote PD_BIGORSMALL as an inline function. Yes, it is quite stupid that two nights of broken builds were needed to bring back these different macro's to mind. How should we resolve this? I'd like to stay with PD_FLOATPRECISION for it's unambiguity (size normally refers to number of bytes, not bits), but on the other hand, PD_FLOATSIZE may already be used by developers of external libs in the meantime. If we can not solve this today, I will undo my changes to creb for the moment, to no longer block the builds. Katja On Mon, Nov 7, 2011 at 5:08 PM, Hans-Christoph Steiner h...@at.or.at wrote: No big thing, we all break the build sometimes :) Thanks for the quick fix. As long as you follow up the next day, don't worry too much about breaking the build. Its only really a problem when we go more than a couple days without builds. But yes, it is better to not break the build ;) .hc On Nov 7, 2011, at 6:51 AM, katja wrote: Found my mistake, affecting single precision i386 and x86_64 builds. It is repaired now. I'll refine my procedures to make sure a mistake like this won't happen again. Apologies for the inconvenience caused by it. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder. - Chris McCormick ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] nightly builds broken
On Tue, Nov 8, 2011 at 1:18 PM, katja katjavet...@gmail.com wrote: There is a small but crucial difference in the API between Pd-extended and Pd-double. In Pd-extended, float precision is defined with PD_FLOATSIZE and in Pd-double it is PD_FLOATPRECISION. This must be resolved before we can continue developing the external libs against Pd-double. And to correct myself once more: I used PD_FLOAT_PRECISION in Pd-double, not PD_FLOATPRECISION. Sigh... Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] getting double fixes into extra/
On Tue, Nov 8, 2011 at 9:04 PM, Hans-Christoph Steiner h...@at.or.at wrote:
Hey Katja,
I was just reviewing the double precision patches for the extra/ section of
pure-data. I think we should try to get Miller to accept the 'extra/' fixes
into pure-data.git now. It seems to me that almost all of these changes are
just float -- t_float, which are really no-brainers that would be really
difficult to imagine causing problems. Plus judging by all the tests you
have written, it looks like your code is already pretty well tested.
In fact I only tested rewritten core functions intensively (on OSX and
Linux), for the extra's I just had a peek at the helpfiles so far, and
checked that there was no ridiculous output during normal use. So, I'm
not sure if it is wise to submit a patch file now. But I will try to
answer your questions below, one by one.
There are only a couple changes in this patch that are not no-brainers. The
first is in sigmund~.c, it looks like you just moved up the #ifdef PD and
#ifdef MSP blocks to the top of the file. Seems harmless enough.
These blocks had to move up because t_float was otherwise not known by
the compiler, for the first part of the code. It is now no longer the
case that the first part can be used without modification in an
arbitrary application, like it used to be the case. An application
programmer using this code for anything else than Pd/MaxMsp, should
define t_float in another way. A comment could be added to mention
that t_float may be float or double?
Then there are a couple places where the code is using 'f' to force
single precision, like:
@@ -677,8 +678,8 @@ static void bonk_doit(t_bonk *x)
{
if (x-x_useloudness)
growth += qrsqrt(qrsqrt(
- power/(h-h_mask[oldmaskphase] + 1.0e-15))) - 1.f;
- else growth += power/(h-h_mask[oldmaskphase] + 1.0e-15) -
1.f;
+ power/(h-h_mask[oldmaskphase] + 1.0e-15))) - 1.;
+ else growth += power/(h-h_mask[oldmaskphase] + 1.0e-15) -
1.;
}
if (!x-x_willattack countup = x-x_masktime)
maskpow *= x-x_maskdecay;
I removed float suffixes consistently from code which I came across.
In the case of 1., 2. etc. this is of no consequence for the actual
value, but for other numbers it is. For example a float 0.001 cast to
double precision becomes 0.001000474974513, while the double could
be precise almost up to it's last digit. There's a nice online applet
'IEEE 754 Converter' on
http://www.h-schmidt.net/FloatApplet/IEEE754.html, showing such
rounding effects. One could use the float suffix to make sure no
redundant typecasts are done, but in the case of code compilable for
single and double precision, it has no advantage to force single
precision.
I have seen it stated on internet that something like 'float f = 1.0'
cannot be compiled in C++, it should be 'float f = 1.0f'. However, in
practice I've not met such problems with C++. Hope this is true on any
platform (otherwise we're stuck).
And cases where there are added typedefs which I don't really understand
what's going on, like:
--- extra_original/expr~/vexp.h 2011-09-06 11:13:12.0 +0200
+++ extra_double_ready/expr~/vexp.h 2011-09-06 11:13:12.0 +0200
@@ -37,6 +37,7 @@
#else /* MSP */
#include ext.h
#include z_dsp.h
+typedef float t_float; // t_float is from m_pd.h
#endif
#include fts_to_pd.h
--- extra_original/fiddle~/fiddle~.c 2010-04-26 00:27:35.0 +0200
+++ extra_double_ready/fiddle~/fiddle~.c 2011-09-06 11:36:28.0
+0200
@@ -108,11 +108,11 @@ static fts_symbol_t *dsp_symbol = 0;
#endif /* MSP */
#ifdef MSP
-#define t_floatarg double
#include ext.h
#include z_dsp.h
#include fft_mayer.proto.h
-
+typedef float t_float;
+typedef double t_floatarg;
#endif /* MSP */
#include math.h
--- extra_original/loop~/loop~.c 2010-07-28 22:55:17.0 +0200
+++ extra_double_ready/loop~/loop~.c 2011-09-06 11:33:54.0 +0200
@@ -14,7 +14,8 @@ This file is downloadable from http://ww
#ifdef PD
#include m_pd.h
#else
-#define t_sample float
+typedef float t_float;
+typedef float t_sample;
#endif
--- extra_original/pd~/pd~.c 2010-07-28 22:55:17.0 +0200
+++ extra_double_ready/pd~/pd~.c 2011-09-06 11:38:12.0 +0200
@@ -26,7 +26,7 @@
#include ext_support.h
#include ext_proto.h
#include ext_obex.h
-
+typedef float t_float;
typedef double t_floatarg;
#define w_symbol w_sym
#define A_SYMBOL A_SYM
Ah these typedefs are nonsense indeed, t_float and t_floatarg are
defined in msp's zdsp.h as well, at least since Max/Msp5, earlier
versions I don't know.
Katja
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
[PD-dev] nightly builds broken
Hello, Yesterday I've committed code to creb and smlib. I have checked that all code compiled, even tested every class's functionality before committing. Even so, all nightly builds are apparently broken due to my commit. I'll now try to find out what went wrong and repair it. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] nightly builds broken
Found my mistake, affecting single precision i386 and x86_64 builds. It is repaired now. I'll refine my procedures to make sure a mistake like this won't happen again. Apologies for the inconvenience caused by it. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] Interruption of audio / Loading sound into array
On Fri, Nov 4, 2011 at 5:21 PM, Mathieu Bouchard ma...@artengine.ca wrote: I don't find anything named like « threaded soundfiler » in the sourceforge tracker, so, it's possible that it hadn't submitted. But that might have been already the time at which we started to doubt that things submitted in the tracker forms were likely to be accepted. Thomas Grill pointed to the code. It is all in the trunk of pure-data.svn: externals/tb/sndfiler and externals/grh/threadlib. But it is not included in the build system. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] svn commit access request, related to double precision pd
Hello Hans, My sourceforge account name is 'katjav'. Thanks for adding me. As mentioned, creb is the first lib tested ok in double precision. In the meantime I've also done smlib. There's unit tests for all objects in both libs. So I'd like to commit code and tests. The question is still where to put the tests in the directory layout, and get them installed. But that question is for another thread. Katja On Thu, Nov 3, 2011 at 3:57 AM, Hans-Christoph Steiner h...@at.or.at wrote: I'm ready to add you, but I couldn't find your sourceforge account name. Can you send it? ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] managing unit tests in SVN
On Thu, Nov 3, 2011 at 3:28 PM, Hans-Christoph Steiner h...@at.or.at wrote: - each library would have a 'unittests' folder for the tests that are specific to that library. Ideally each object would have a test patch in the 'unittests' subfolder in the library, but we're a ways off of that. If I understand you well, one would get a subdir 'unittests' for every lib like so: externals/creb/unittest/, externals/miXed/cyclone/unittest/, externals/unauthorized/unittest/ etc. A copy of the test abstractions should be in every lib's unittest/ dir, no? (In case a lib is copied individually from SVN). A few remarks on unit test abstractions. There's two flavours now: - [unit-test-frame~] for signal objects - [unit-test-frame] for control objects with numeric output (floats and/or lists of floats) Both flavours store a 512 points reference file as 32 bit float .wav, the most precise storage method in single precision vanilla Pd. See http://www.katjaas.nl/pdunittests/pdunittests.html for screenshots and .zip file with abstractions and some examples. Of course, when testing an object, all other objects in the test patch are part of the system under test as well. This is not only a theoretic concern, as I soon found when testing double-precision-built externals against their Pd-extended 0.42 reference. Signal classes in Pd are designed for speed, not for accuracy. It is sometimes inevitable to accumulate inaccuracies, for example when using [phasor~] as test input signal for a filter object. Obviously, it is impossible to test the exact accuracy of double precision objects against a reference in single precision. Large deviations tell real troubles, that is where the tests are most useful. For example, when a double is read as type float due to erroneous pointer aliasing, output is totally ridiculous. Or aggressive optimization may sometimes induce unintended order of operations, mostly leading to crap output. For all creb and smlib classes, unit tests are now written in this sense, over 70 tests together. A fraction of the total to be done for Pd-extended. Test development still takes more time than the actual rewriting of bits in the code, even while the test abstractions save loads of work. But for Pd-double in particular, it is indispensable. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] managing unit tests in SVN
On Thu, Nov 3, 2011 at 10:06 PM, Hans-Christoph Steiner h...@at.or.at wrote: I think the test abstractions should probably be distributed as a regular library, and included in Pd-extended. That is easier to manage indeed. So you would have externals/unittests/ with abstractions, and dirs like externals/creb/unittests/ with the actual tests, only working when the unittest lib is loaded. With the unit tests being dependent on a unittests lib, there should be a readme in each lib's unittests/ subdir about that. Additional unit test abstractions could be developed, for example to test objects with symbol output messages. But wait, does it all make sense The unit tests are in SVN, but not included in the build packages. Why have externals/unittest/ lib then? Or is it your intention to include unit tests in the distributed builds as well? Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] svn commit access request, related to double precision pd
Hello dev list, In recent months I changed some lines in Pd core code to make it double-precision-compilable. I'd like to help a bit with making Pd-extended ready for double precision as well. After puzzling on repository layout and build system, and figuring out a decent test method (together with Fred Jan Kraan), I am now ready to commit rewritten lines for one external lib, creb. It is for this library that I want to request commit access now, but it doesn't stop here. A brief description of the project: Pd-double is a fork of Miller Puckette's Pure Data, patched with mentioned double-ready lines. It has (and will continue to have) the same API, apart from the option to compile in single or double precision at will. Pd-double enables double precision builds of vanilla Pd, and is tested to work well on OSX and Linux. I still have to work on the Windows side of things. In the meantime Pd-double is useful as a framework against which external libraries can be developed towards double-readiness. A usable development setup is described on http://puredata.info/dev/pd-double/PdDoubleDevelopment. Convenient unit-test abstractions are introduced here: http://www.katjaas.nl/pdunittests/pdunittests.html. I'd like to invite all Pd-devs to join in. Rewriting and testing classes assumes a fair knowledge of their functioning, and Pd-extended is huge. For me, doing one lib at a time works well, thoroughly testing the whole of it before committing. When starting on another lib, I'll ask commit access again. I could also submit patch files instead, if that is preferred in some case. A few words on my background so you know who's wanting to poke in your code. During a one-year course at the Sonology Department of the Hague Conservatory (Holland), I learned the basics of dsp math and programming. That was 2007-2008, and I've never stopped music programming since, documenting my efforts and experiments on www.katjaas.nl. Pd has become my favourite environment, because of it's open source and active community, and because I like how you can prototype a neat audio tool quite fast, with GUI and all, while C code is still an option to solve details. A few Pd-externals and projects are shared online via mentioned site (nb 'slicycle' stuff and [soundtouch~]). I teach Pd workshops sometimes. The single-precisioness of Pd has been my only serious gripe. See http://www.katjaas.nl/doubleprecision/doubleprecision.html for illustrations of precision-bottlenecks. Working on this topic, I hope to contribute to the wonderful tool and the community supporting it. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] signal object test template for automated unit testing
Reorganized the unit test abstraction once more, now I'm really happy with it. Thanks for all the useful suggestions everyone. I will not spam the list with my patches anymore, it is here, with screenshots, explanation and .zip: http://www.katjaas.nl/pdunittests/pdunittests.html Please have a look at it, try it out. There's a few examples which should clarify the idea. In my experience, it takes on average a couple of minutes to create a test patch this way. I hope it is now decent enough to become part of a standardized method for testing Pd-extended. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] signal object test template for automated unit testing
Sorry, there's a bizarre bug in unit-test-frame~.pd. Don't try to use it at the moment, it's confusing. Loadbanged delay time is different from buttonbanged delay time, even when loadbang activates buttonbang directly. Need to find a workaround. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pd without audio device (was: signal object test template for automated unit testing)
On Tue, Oct 25, 2011 at 4:11 PM, Roman Haefeli reduz...@gmail.com wrote: On Mon, 2011-10-24 at 22:11 +0200, katja wrote: By the way if Pd does not sync with an audio device for whatever reason, you get weird test results anyhow. Even if you do not want to actually hear the sound, the audio device must work well, for these signal object tests. That was one of the first things we observed in practice. Can you elaborate on that? I used to use Pd setups without real audio device (for instance running Pd on a server producing an Icecast stream) and I never found anything odd. Probably it happens only under certain circumstances? Anyway, I'm interested to hear more about it as I always assumed that -noaudio should lead to same result as with audio (synced to a real device). Roman you're right, a -noaudio Pd doesn't sync with a device and therefore it can not have sync problems. Thanks for pointing to this. It did not cross my mind to do signal tests with -noaudio but it may be a good idea, to exclude sync troubles in any case. Pd started with -noaudio is the same as Pd with input- and output- devices disabled, and this can also be done with an audio-dialog message. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] signal object test template for automated unit testing
Hans, thanks for your comments On Mon, Oct 24, 2011 at 7:35 PM, Hans-Christoph Steiner h...@at.or.at wrote: That looks really good on many levels. :) I like the layout, I hadn't thought of standard deviation, that makes sense as long as we can specify exact as a possibility. My guess is that some of this stuff should produce the same bit sequence every time, but I could be wrong there. If you specify tolerance zero, that's exact. But we found that tolerance is needed for different reasons: - floats are stored as text by Pd, and differences between computed and stored values occur because of the truncated stored floats - there's small differences between single precision and double precision Pd - objects with a 'memory' (like IIR filters) produce slightly different results if you test them repeatedly with the same input sequence Perhaps the subpatches should be abstractions as part of a 'test' library. If there was a bug or a new feature needed in any of those subpatches, it would be rough to have to modify all of the tests. Of course, thanks. I'll redesign it in that sense. About the sample rate, it should be possible to have each patch set the sample rate it needs. You can see hcs/get-audio-dialog-help.pd or the mediasettings library for ways to do that. I think we'll want to test at different sample rates some day, but if its easier for now, we can stick to 44100. The idea was to only use vanilla objects around the object under test, so you don't depend on external libs for testing. Do you know if it's possible to send standard messages like 'audio-dialog 1 0 0 0 2 0 0 0 0 0 0 0 2 0 0 0 44100 20 0' or 'audio-dialog 1 0 0 0 2 0 0 0 0 0 0 0 2 0 0 0 48000 20 0' to pd on all systems, without requesting data first? I don't think so. If the device has different number of channels (instead of 2), Pd can not sync. And if the device doesn't allow the alternative samplerate, it won't work either. Samplerate 44100 is safest. By the way if Pd does not sync with an audio device for whatever reason, you get weird test results anyhow. Even if you do not want to actually hear the sound, the audio device must work well, for these signal object tests. That was one of the first things we observed in practice. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-double builds are actually double now
Starting on October 20, nightly builds tagged as pd-double are really built in double precision. All earlier builds were single precision or a mix of single and double. In double precision, only Linux builds succeed, partly. From the logs, you can see gcc exiting with an error when compiling creb. The package contains everything which was built before creb: the Pd core and a few external libs. On OSX, no package is produced at all. It will take considerable time before all libs will even compile in double precision, since all fixes have to be properly tested before commit. In the meantime, double precision Pd builds were prematurely announced on puredata.info on Otober 4. We have two weeks of wrecked pd-double builds on the autobuild pages, but the pd-double announcement is already leading it's own viral life, see for example an aside in this thread (Pd forum): http://puredata.hurleur.com/sujet-6287-filter-object-bug-iemlib I am now looking for a way to better manage info and support on this topic. The double-readiness of pd core code is a modest achievement, a seed from which double-precision-enabled Pd / Pd-extended will hopefully grow. This perspective may be easily be overshadowed by reports of disappointment when pd users can not find executables, or even worse, test the wrecked builds. An early conclusion will be that double-precision Pd is a pathetic failure, and this may in turn discourage further development. Would it be possible to have double-precision vanilla Pd builds produced for all OS'ses, and make them available via puredata.info? I can include test- and demo-patches, and we could set up a place to collect such patches from users. This would be a positive way to get a taste of double-precision Pd. The nightly pd-double builds instead, are at the moment only useful for hardcore testers, devs and maintainers, they can not help in promoting the topic among pd users. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-double: how to selectively build external libs for development?
On Thu, Oct 20, 2011 at 12:05 AM, Hans-Christoph Steiner h...@at.or.at wrote: AH, right, you need to include a symlink to src/ called bin/ then it should all work. I do this a lot, so I know it works once it setup. But I might not always remember the details on setting it up: So like this: cd pd-double/pd ln -s src bin Thanks, Hans. Here is the source of all confusion: once a local install is done in pd-double/ with the new build system, external dirs should go in pd-double/lib/pd/extra/, not pd-double/extra/. I overlooked this. Moreover, this path remains until pd-double/lib/pd/extra/ is deleted, no matter if you make clean and build without install. So this is what nagged me a couple of days. Would be nice to have such details documented. Once I'll be settled on the best way to develop externals against pd-double, I'll document it on puredata.info anyway. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-double: how to selectively build external libs for development?
Finally got it figured out, how to conveniently develop external libs against pd-double. Documented on: http://puredata.info/dev/pd-double/PdDoubleDevelopment It's derived from Hans' suggestions, and descriptions on puredata.info wiki pages, but I've only written down what I've seen working with my own eyes. In the end, it is not even too complicated. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-double: how to selectively build external libs for development?
On Wed, Oct 19, 2011 at 9:32 PM, Hans-Christoph Steiner h...@at.or.at wrote: I think skipping 'make install' alltogether and just running things directly is much easier for dev work. Something like this: cd pd-double/pd ./autogen.sh ./configure --enable-double-precision make cd extra ln -s ../../externals/creb cd .. ./src/pd Now you have a way to run pd-double's Pd using the creb you are working on. Then to build creb after mods, just do: cd pd-double/externals make creb Hi Hans, Regarding a 'local build', there is some difference in the two build systems for vanilla Pd (old/new) and the new build system is causing me troubles, let me try to explain. With the old build system, if you did make without install, it would create a local dir 'bin/' and copy executables pd, pd-watchdog, pdreceive and pdsend into it. The directory structure of the local build was very similar to the 'Resources' dir in a Pd or Pd-extended app on OSX. If you put an externals dir in 'extra/', Pd would see that dir. I've checked that this is also the case for double precision pd which I built with the old build system (before we had pd-double git). I can just copy a double precision creb dir with executables into 'extra/', see creb in the help browser, and instantiate creb objects (with namespace, that is). With the new build system instead, if you do not install, the executables pd, pd-watchdog, pdreceive and pdsend remain in the 'src/' dir. You can start pd from there, but it won't find it's extra's. I've tried several approaches to make it look like a local install (manually creating a 'bin/' with pd executables, alternatively ./configure --prefix=/my/path/to/pd-svn/pd/). This helps - to a certain extent. The regular extra's that come with vanilla Pd are found. But if you add an external lib dir... no fun. The old build system was much more convenient for local test builds. We've removed it from pd-double but I will try it in my hacked pd-svn tomorrow, to see if things work better. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-double: how to selectively build external libs for development?
On Tue, Oct 18, 2011 at 8:33 PM, Hans-Christoph Steiner h...@at.or.at wrote: Another idea for handling this is to use the ./configure --enable-double-precision flag, but have it generate a config.h, which is included by m_pd.h. That should solve this issue, since config.h would be auto-generated based on the flag, but all externals would use m_pd.h, which reads the PD_FLOAT_PRECISION value from config.h Ah yes that sounds like a good solution. But what if a lib is built without ./configure? If config.h is included by m_pd.h, it must always be there, no matter how you build. This config.h then becomes part of the API. And ./configure, if called upon, will simply overwrite config.h, no? And thus change the API, in effect. I don't know, maybe that's a theoretical issue only. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-double: how to selectively build external libs for development?
Tried all day to build some of pd-double in pd-svn, but what worked yesterday stopped working today, after svn update. Well update, it was a fresh checkout for compelling reasons. Here is an updated version of how to build things selectively: - clone pd-double.git (pd-double') - checkout pure-data.svn (pd-svn) - replace sources in pd-svn/pd/ with the sources from pd-double - from within pd-svn/pd/, build pd with: - ./autogen.sh - ./configure --prefix=/my/path/to/pd-svn/pd/ - make install - from within pd-svn/externals, selectively build a lib, like so: make DESTDIR=/my/path/to/pd-svn/pd/ creb_clean creb creb_install - the external lib will be installed in pd-svn/pd/extra/ - do not try to update pd-svn/pd/ ! This builds all the stuff and installs into the appropriate places within pd-svn/pd/, with pd in pd-svn/pd/bin/. The extra's and creb are in pd-svn/pd/extra/. But now the frustration: creb is not visible in the help browser, and it's objects can not even be loaded with namespaces, like [creb/blosc~]. I'm 100 % sure that I've instantiated [creb/blosc~] and other creb objects yesterday in a similar dev setup. As a last resort, I've built (almost) the whole of Pd-extended from pd-svn/packages/darwin_app/, just to see double precision [creb/blosc~] loading once more. But for development, this does not work since all the cleaning and compilation is done for all libs everytime, it takes over 10 minutes to build. I really need the selective approach to work. How come pd sees all the stuff in it's extra dir, except creb? Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] external libs that refuse double precision compilation
On Fri, Oct 14, 2011 at 5:27 AM, Hans-Christoph Steiner h...@at.or.at wrote: On Oct 13, 2011, at 8:37 PM, katja wrote: Indeed I stumbled upon that extra extra when trying to find the puzzling cause of errors. They are not in sync, externals/extra has the old code, that's why it fails to build. The extra's in pd-double.git and are double-ready. Hmm, are you sure? I just re-copied the files from pure-data.git to externals/extra and svn tells me there is no difference. The do have different build systems, but the .pd, .c, and .h files I think are all the same. Yes externals/extra are the same as the extra's in pure-data.git, with all the floats still there, instead of t_float. If externals/extra can be synched with the extra's in pd-double.git, we're fine. I've added a daily type-punning log that just grabs the gcc warning from the build logs and consolidates them, its posted here every day: http://autobuild.puredata.info/auto-build/2011-10-13/logs/type-punning.log Very useful. It's quite a list, but be sure it's not complete! When looking at the logs, I also found that today's macosx106-x86_64 pd-double autobuild failed. That was to be expected. Because of the precision-to-bitness coupling in m_pd.h, it was now building the externals in double precision for the first time (the earlier builds all have single precision externals). gcc exited with an error when compiling creb, just like I've seen it on my own computer. The point is, I have no clue how to create a dev setup for even the simplest commit. I was mimicking the nightly build on my computer just to see where problems are, which libs do not compile etc. But it's not a useful route for development. On the other hand, in a local pd-svn, externals can only be built against pd-double when old pd is overwritten with pd-double.git. But then it's no longer a working copy of pure-data SVN, and does not allow for update or commit. And from within pd-double git dir, I could not get an external lib to be built with the symlink method as described on puredata.info. Pd-double-extended has a very weird status: partly it's a branch or fork, partly it's a form of bugfixing. So you can commit untested changes which are safe, like changing float into t_float, and then in the nightly build check if it worked out well with pd-double. But some modifications, for example the replacement of Hoeldrich style routines and other type punning stuff, must be tested thoroughly on functionality, robustness and performance before committing. By lack of a formal branch where all the double-ready code is unified, this work can only be done locally, with a dev set up yet to figure out. In any case, such substantial rewrites can be submitted to the patch tracker, so others can test them before they're committed. It won't concern too many cases. For example, in the core, less than ten classes on a total of ~200 needed a fundamental redefinition to make them double-ready. (Even so I've spent over a month on that, due to unfamiliarity with pd's core code). Is this an idea? - simple changes like float t_float: untested, via SVN - substantial function redefinitions: via patch tracker In this way, the fact that one can't build and test for pd-double in pd-svn is less of a problem. Then we can think about a dev set up from where you'd only produce patch files, and not commit to SVN. That should give more options of how to organize it. At the same time, it gives some guarantee that redefinitions with possible performance- or functionality- consequences are not committed too fast. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] recent pd-double nightly builds crash at start up
On Wed, Oct 12, 2011 at 2:49 PM, katja katjavet...@gmail.com wrote: OK thanks, it's clear now. The nightly builds do not support targets other then where the build happens. No, must eat my words. The Makefile for darwin_app in the autobuild has: export MACOSX_DEPLOYMENT_TARGET = 10.4 Theoretically the 10.6 build should support older OS'es, also with respect to lib loading. Pity it doesn't work in practice. Found no useful hint for the specific case yet. Will now try to produce a 'nightly' build on my OSX 10.5 laptop. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] pd-double: how to selectively build external libs for development?
Today I wanted to find out what cyclone needs to be made double-precision-ready. To start with, I tried to just build the current code together with the pd-double core. I followed the howto on http://puredata.info/docs/developer/WorkingWithPdExtendedSources to get the sources complete, with the difference that core code is in pd-double.git instead of pd-extended.git. For developing I wanted to use 'Selective Approach' as discussed on mentioned page. In my pd-double/extra/ I created a symbolic link to my pd-svn/externals/miXed/cyclone. Then the howto says: 'Build everything inside pd-extended.git'. I did that with: ./autogen.sh ./configure --enable-double-precision sudo make install A double precision pd is built as usual, but not with cyclone included. Funny enough, cyclone showed up as an (empty) entry amidst the extra's in the help browser, when I loaded the freshly built pd for the first time. But the second time that was gone. What should I do to include cyclone in the build process? Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] Fwd: pd double autobuilds
On Sat, Oct 8, 2011 at 4:51 PM, Hans-Christoph Steiner h...@at.or.at wrote: And yes, vanilla/ is an experiment in splitting out the internals into a library. This allows people to write highly optimized versions of it for specific situations, like specific CPUs, and then use and distribute them easily. Ah, I see. If loaded, vanilla/ takes precedence over the corresponding core class definitions. I noticed classes like sqrt~ which have double-incompatible definitions so vanilla/ requires some modifications. Further I would like to work on cyclone as there are Hoeldrich style routines in it. I'll send an SVN write access request to the dev list, for these modules to start with. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd double autobuilds
On Sat, Oct 8, 2011 at 11:37 PM, Hans-Christoph Steiner h...@at.or.at wrote: Ok, I figured out why the nightly auto-builds were always 32-bit. The whole Pd-extended build sets CFLAGS= when calling make, and the precision was being set in ./configure in CFLAGS, so it was being overridden by the 'make CFLAGS=-O2 -g'. I changed it to use AC_DEFINE so its set in DEFS, and now CFLAGS is not overriding it. So tomorrow's build should actually be 64-bit. Hans, Pd-0.43.1-double-20111009-macosx106-x86_64.dmg has double precision indeed, it shows 'PD_FLOATPRECISION = 64 bits' at startup and core objects work correctly. At the moment I can not verify that externals are also built in double precision. There's a lot of nonsensical output from objects but this may be caused by their code as well. We're facing a period of intensive bugfixing, that's for sure. Double precision Pd extended is now a mutant. Part of it's DNA has changed and it's crippled. In fact it is in a disastrous state, but still I'm as excited as when I saw double precision in my own builds for the first time. I hope the project will survive impatience, disappointments and distractions. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-double builds are actually double now
On Sun, Oct 9, 2011 at 9:43 PM, Hans-Christoph Steiner h...@at.or.at wrote: Ok, I just tested the Mac OS X 64-bit build of Pd-double and it is indeed double precision. I say we start announcing it and spreading the word to get people testing it, and maybe fixing up their code and/or contributing to fixing things. Katya, do you want to post such an announcement to pd-announce? I think we should also try to get it posted on the Create Digital Music blog. It would nice to have example patches of what double precision enables. I'll do one that uses 32-bit int timestamps. Yeah it's now the right time to announce things and at the same time be clear about what to expect and what to not (yet) expect from pd double extended. Tomorrow I'll have time to do some detailed announcements. Could we collect tests patches somewhere? I have a lot of testpatches already in the original set on: http://www.katjaas.nl/doubleprecision/doubleprecision.html (page bottom) Most of these are functional tests and performance tests, but there's also a directory 'precision-tests' with examples, some of which are also shown on mentioned page. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] pd double autobuilds
Hans, I'm sorry to say that Pd-0.43.1-double-20111007-macosx106-x86_64.dmg is again a single precision build. If I build from the pd-double.git sources, an i386 build with 32 bit float precision is the default output. This may be so because I am on OSX 10.5. I've pushed a change to pd-double.git, to display the precision message at start up with log level 2 instead of 3, so the message won't go unnoticed. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd double autobuilds
On Fri, Oct 7, 2011 at 5:19 PM, Hans-Christoph Steiner h...@at.or.at wrote: But I guess then these nightly builds don't help you that much, since you're on 10.5. In itself Pd-0.43.1-double-20111007-macosx106-x86_64.dmg runs without trouble on OSX 10.5. But: - preference file org.puredata.pd.plist is read, this is vanilla's preference file - therefore, no external libs loaded at startup For the moment, this may be an advantage. If we make test patches using namespaces for all external objects, like [zexy/limiter] etc, these patches will load the correct object for any Pd-extended install on the computer. When loading libs with help of the preference file, this is not guaranteed.* The only disadvantage is, you can not load an arbitrary patch which does not use namespaces. Katja * Here's an example. Pd-0.43.1-extended-20111002.app tries to load: /Applications/Pdextended.app/Contents/Resources/extra/iemlib/iem_anything.pd_darwin: dlopen(/Applications/Pdextended.app/Contents/Resources/extra/iemlib/iem_anything.pd_darwin, 10): no suitable image found. Did find: /Applications/Pdextended.app/Contents/Resources/extra/iemlib/iem_anything.pd_darwin: mach-o, but wrong architecture ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] pd double autobuilds
On Sat, Oct 8, 2011 at 12:08 AM, Hans-Christoph Steiner h...@at.or.at wrote: I think this is caused by using the 10.6 build on 10.5. It is only partially compatible. Pd-0.43.1-extended-20111002.app, an x86_64 build, tries to load libs from Pd-extended.app which is an i386 build. That's where the message 'wrong architecture' comes from. In Pd-0.43.1-double-20111007.app, objects from iemlib and other libs can be perfectly instantiated with namespaces. There's no compatibility problem, the extended objects are working as usual. Because it's all single precision still. It's compiled with PD_FLOAT_PRECISION 32, the core code as well. Shall we not better start another repo with a clone of the full pd-extended.git to work on? Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] double precision Pd: .patch files, tests and benchmarks
On Wed, Oct 5, 2011 at 6:11 AM, Hans-Christoph Steiner h...@at.or.at wrote: So you are saying that the stuff in pd-double is not building using 64-bit floats? I downloaded Pd-0.43.1-double-20111003-macosx106-x86_64.dmg from the auto-build and this one was single precision. Don't know about the other builds. Maybe it's better, for the moment at least, to set logpost level 2 for the precision message at startup so you see it immediately. I used log level 3 in accordance with your intention to start Pd with a clean window, but in the testing phase this makes no sense indeed. Let's get a github repo going so we can work on this stuff. Unless you want to, I'll happily set one up at: https://github.com/pd-projects/pd-double Yes please if you want to, go ahead. I'm slow with these things, by lack of experience. I even still have to learn git, and was comparing features of github vs gitorious. Both seem fine. In the meantime I'll work on a clean up of rewritten code then, and based on pure-data.git instead of 0.43-0. Thanks for the very supportive cooperation. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
On Tue, Oct 4, 2011 at 11:38 AM, IOhannes m zmoelnig zmoel...@iem.at wrote: the proper way is to use CPPFLAGS=-DPD_FLOAT_PRECISION=64, But now you undo the CPPFLAGS as defined in the makefile. I didn't know how to add to the CFLAGS from the command line, but found a solution here: http://theory.uwinnipeg.ca/localfiles/infofiles/make/make_66.html#SEC65 It requires a small adaptation to the makefile. Instead of: CFLAGS = comes: override CFLAGS += . Now you can add to CFLAGS from the command line, like so: make CFLAGS=-DPD_FLOAT_PRECISION=64 Note that the CFLAGS in the makefile now have precedence and you can only add to it from the command line, not override it. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
2011/10/5 Hans-Christoph Steiner h...@at.or.at: I removed the old build system from pd-double.git and pushed the change. Hopefully that'll reduce confusion. Yeah I was using the old build system all the time because it was so easy to produce local builds by doing make without install. Never mind. Katja. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
On Tue, Oct 4, 2011 at 1:33 AM, Hans-Christoph Steiner h...@at.or.at wrote: And we have our first Pd-double build! http://autobuild.puredata.info/auto-build/2011-10-03/Pd-0.43.1-double-20111003 macosx106-x86_64.dmg Cool Hans! Can't wait to check it out (though I'll have to wait till I get home tonight). Yesterday I forgot to mention why it should definitely not be built with -O0 (unless for debug purposes): PD_BIGORSMALL is defined an inline function (like it was already suggested by IOhannes a while ago), but at -O0 nothing will be inlined. A benchmark howto would be useful indeed. By the way for my coreduo 1.83 GHZ I could compile for Debian with SSE by setting -march=prescott, this was the last 32bit adress space SSE enabled CPU. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
On Tue, Oct 4, 2011 at 9:06 AM, katja katjavet...@gmail.com wrote: By the way for my coreduo 1.83 GHZ I could compile for Debian with SSE by setting -march=prescott, this was the last 32bit adress space SSE enabled CPU. Sorry, correction again: of course coreduo is also 32bit address space but it is not in the list of possible arch definitions for gcc. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
Hello, Happy to see so many test results from IOhannes. The 'perfotest' patches were initially created for function profiling, to check if there are particularly time consuming instructions. To mention a funny example: I was happy to see that fabs() was translated to a single instruction ANDPS / ANDPD for xmm registers. But for the FPU it is a call. The same for isnan(). That's why PD_BIGORSMALL must still do a bitpattern check on aliased floats. For benchmarking original and double-ready Pd as a whole, I used two (fairly cool and elaborate) patches which were written in pure vanilla: - Chaosmonster1 from www.martin-brinkmann.de (10 instances or so) - Cave of Creation by Hamster, http://puredata.hurleur.com/sujet-5080-2.html Both works feature enough of the rewritten code to make them representative overall benchmarks. If double-ready Pd performs as well as original Pd with usual compiler settings, on all possible platforms, I would be satisfied. After all, the purpose of the whole thing was to get some more decimal places in our numbers, not to make Pd run faster. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
Forgot to mention this: at start up there's a logpost (level 3) 'PD_FLOATPRECISION=32 bits' for single and 'PD_FLOATPRECISION=64 bits' for double build. Ah, so tomorrow a single and double precision build will automatically be made? Cool. It's confusing. At the moment there is vanilla Pd patched to work in double precision. But for Pd-extended it is: a single precision Pd-extended with double-ready core code. Not a double precision Pd-extended, not even double-ready Pd-extended. Let's better call it something like Pd-0.43.1-single-20111004-macosx106-x86_64.dmg etc., Hans? Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] double precision Pd: .patch files, tests and benchmarks
On Sun, Oct 2, 2011 at 11:36 PM, Hans-Christoph Steiner h...@at.or.at wrote: I think it makes sense to work off of pure-data.git rather than pd-extended.git since this is a patch targetted at getting into Miller's repo. Right. Even then, we could add some external libs to work on, starting with zexy and cyclone for example. The question is how to load appropriate executables into local single and double precision test builds of vanilla Pd. A single preference file is shared by all vanilla Pd installations, therefore setting searchpaths via preferences is no option. Each Pd should only load from it's own 'extra' directory. With the extra's included in vanilla Pd, this works fine as far as I have seen. I tested bonk~ in single and double precision Pd simultaneously without symbol collision. As for arch issues, I think Intel and ARM are the big ones to test these days. But PPC is fine too. Expressed in number of 'users', ARM is probably the most popular target hardware for Pd at the moment. It should be easy to patch libpd with the same .patch files, or not? Some modified files are inexistent in libpd (s_audio_pa.c, vexpr.c etc). It's important to at least benchmark-test rewritten code on this hardware indeed, if we want to make a unified doube-precision-ready Pd happen. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
Thanks IOhannes for all your comments and suggestions. I just realized that there are several ways in which identical symbols for different function definitions could cause a problem and I did not distinguish them. 1. Pd looks for a setup symbol when trying to load an external binary. 2. A loaded external calls an exported function in Pd. 3. Pd calls an exported function in Pd Case 2. and 3. can only lead to symbol collision when a single precision and double precision Pd are running simultaneously. So far, I have not seen symbol collision happen though I've often ran them simultaneously. I understand that theoretically it's not guaranteed that it won't happen, that's also the reason why it is generally recommended to only export truly global symbols. However I think it is not really a concern, as there is normally no reason to run single and double precision Pd together, apart from testing purposes. For case 1., protection is needed indeed. As IOhannes' list of possible approaches indicates, it's not a trivial intervention. I've also been thinking of a mechanism where Pd 'probes' a class at load time in order to find it's float type before instantiating any object. Rather it creates a private test instance for that purpose and tries to solicit output and check the size. To program this is not trivial either, if possible at all, but the advantage would be that it does not have consequence for class code. Actually I think we have time to find and implement a solution because during the double precision development and test period we do not depend on it. If only we find a good way to point different Pd installations to subdirs in their own 'extra' for loading externals. What I meant to say in my previous mail is, that external executables like bonk~ are found from the proper location because Pd apparently knows they are in it's own extra dir, wherever the installation may be located. I do not know where this path is set but we need an option to add more dirs to that local path without using preferences. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
On Mon, Oct 3, 2011 at 4:35 PM, Hans-Christoph Steiner h...@at.or.at wrote: Do you have access to an ARM machine? If not, I could probably get one online with ssh access, if that's useful. I've mailed Joe White with the question if he can patch the code for libpd and check performance on ARM. He has done some extremely popular RjDj apps and needed to optimize for them as well. Think it would be good anyway to keep in touch with libpd users and app programmers about this topic, even though we're in an early stage with it. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
On Mon, Oct 3, 2011 at 6:21 PM, IOhannes m zmoelnig zmoel...@iem.at wrote: apropos performance: on my i5 650 @ 3.2GHz, running debian and trying to osc-delay-perfotest.pd (with only 400 osc-delay abstractions, as 500 would max out the CPU in new double mode) i get: original : 28% debian : 31% new single: 64% new double: 86% Did you build new single / new double without any optimization? Makefile.am/in for Pd-0.43.1-test4 do not specify optimization. I compared using -O2 for all builds, like it is set for Pd-0.43-0. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
On Mon, Oct 3, 2011 at 7:08 PM, katja katjavet...@gmail.com wrote: On Mon, Oct 3, 2011 at 6:21 PM, IOhannes m zmoelnig zmoel...@iem.at wrote: apropos performance: on my i5 650 @ 3.2GHz, running debian and trying to osc-delay-perfotest.pd (with only 400 osc-delay abstractions, as 500 would max out the CPU in new double mode) i get: original : 28% debian : 31% new single: 64% new double: 86% Did you build new single / new double without any optimization? Makefile.am/in for Pd-0.43.1-test4 do not specify optimization. I compared using -O2 for all builds, like it is set for Pd-0.43-0. Katja Update: The rewritten code is more sensitive to optimization than the original. On coreduo 1.83 GHz with Debian I could only run 200 osc-delay abstractions in osc-delay-perfotest.pd under worst conditions. Compare these values from command top: original: 69% with -O0, 47% with -O2 (no SSE) new-single: 83% with -O0, 48% with -O2 (no SSE) new-double: 97% with -O0, 59% with -O2 (no SSE) On MacBook core2duo 2GHz where I wrote and optimized most, 500 osc-delay abstractions can easily run in osc-delay-perfotest.pd, with these values from top: original: 60% with -O3 and SSE new-single: 50% with -O3 and SSE new-double: 54% with -O3 and SSE I knew on beforehand that the code would get tuned (performance-wise) to hardware, instruction set, OS, compiler, compiler options etc. used for development, but it never crossed my mind to check performance with optimization level -O0. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
Hi Hans, Thanks for your detailed comments. I will go through the code once again, you're right it's not as clean as could be. Regarding your suggestion to set up a repo, it seems to be the most logical thing to do. This could be considered a temporary branch for the double precision thing, to be discontinued once all the code works fine for single and double precision alike and merged into Pd. I'll start that up one of these days (my first repo ever, hope to get it done...). A few words on the scope of tests done so far. Rewritten code was developed and tested on Intel core CPU's, where it seems to work smooth, both with SSE and FPU instructions. Regarding functionality and robustness, I have good confidence that it will work anywhere, as it's simple and depends only on standard libs. But considering performance, more checking is needed. The rewritten phase-wrapping classes have branches in the perform-loops. These are only executed in rare cases, therefore branch prediction mechanisms can do their good work. But on older architectures branching may be more expensive. That was also the reason for Miller's branchless design of these classes, of course. PPC in particular should be considered, as there are still quite a few users. Maybe the code needs some finetuning to PPC. Only after settling this aspect, I would consider submitting the double-precision-ready .patch file for Pd's core code. Otherwise I'd risk an endless series of amendements on a submitted patch. In the meantime, double precision ready code would be available from this git repo we're planning. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] double precision Pd: .patch files, tests and benchmarks
Hello, Finally my double-precision-Pd efforts resulted in code decent enough to be useful in practice. It's all documented on: http://www.katjaas.nl/doubleprecision/doubleprecision.html From there you can download a .zip with two .patch files to make vanilla Pd 0.43-0 double precision ready. In fact what you have is 'arbitrary-precision' code which can be built for single or double precision with the setting of a single definition in the API header m_pd.h. Test patches are included. So far, I have tested on OSX and Linux. Remarkably, double precision Pd performance is comparable to current Pd on the Intel CPU's. The only drawback that I can think of is, it eats memory. This would be a bummer for Pd users doing Ableton style stuff with lots of soundfiles to be loaded into RAM. Krzysztof Czaja already warned me for this at Pd Con, but at the time I forgot a bit about the problems with loading soundfiles during a live session. For me, as a precision freak, it is a delight to work with double precision Pd. Some examples are illustrated on mentioned webpage. Unfortunately, my music stuff needs Pd extended. I would be happy to continue the project. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] [soundtouch~] pitch shifter for Pure Data
sorry the previous mail went to the wrong list. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] [soundtouch~] pitch shifter for Pure Data
On Fri, Sep 16, 2011 at 6:52 PM, Hans-Christoph Steiner h...@at.or.atwrote: hey Katja, I am trying your soundtouch~ on Ubuntu/Maverick. First I tried the included binary, then I built it from source. Both ways I got this: soundtouch~.pd_linux: soundtouch~.pd_linux: undefined symbol: _Znaj Are you building for a 64 bit system? I have tried that several times, and can't remember all the details, but that wouldn't make much of a difference because so far I never succeeded to make it load. For Linux 32 bit (Ubuntu, Debian), I have not seen this issue. But I don't know by head which gcc version was used for these. When building the soundtouch~ class for Windows with latest mingw, I had a problem with missing libs, and this could be solved by including cflags; -static-libgcc -static-libstdc++ For what I understand this is a specific feature of mingw, where they have (recently) split the gnu standard library in smaller units, for which you can choose to include them statically or supply dll's. I have noticed the discussion on the list about this topic. But now I wonder if 64 bit Linux, or maybe gcc 4.5, have adopted a similar approach? I am mostly on OSX and Debian with not so new GNU tools. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] preparing phasor~Co. for double precision Pd
2011/7/30 IOhannes m zmölnig zmoel...@iem.at wrote: looking at the code, the relevant changes are definitely there for jack; and alsa will most likely work if it's not trying to do mmap() - if the device does support mmap we might have problems. In s_audio_alsamm.c there is an implicit typecast from t_sample to float in line 1208 where the samples are copied (function alsamm_send_dacs()). And for the input a typecast is at line 1316. This makes me think doubles could work with alsa mmap as well. Can't test it though. I will not have time to work on the Pd double precision thing till after Pd con, but will resume testing later, on OSX, Linux and maybe Windows. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] preparing phasor~Co. for double precision Pd
Managed to get a double precision Pd working with PortAudio, after small modifications in s_audio_pa.c. In function pa_open_audio(), *soundin and *soundout (pointers to type t_sample) used to be aliased to *pa_soundin resp. *pa_soundout, pointers to type float. If instead, *pa_soundin and *pa_soundout (and it's own aliases) are declared of type t_sample, the hard copying of samples from PortAudion arrays to Pd arrays and vice versa does the typecast between types of different sizes correctly (tested for Pd 0.42.6, I'll do it for 0.43 soon as possible). Since I am not familiar with this part of Pd code, my proceedings are slow and I've not found the time to scan s_audio_jack.c, s_audio_alsa.c etcetera for similar issues. Yet, on the dsp side of things, I feel we're close to a properly functioning double precision Pd. In the meantime I'd like to toss another topic of concern. While testing, I found that a single precision Pd can easily load double precision executables if they are present in the search path for some reason. The other way round will undoubtedly be possible as well - the C symbols in single and double precision builds are identical. Pd crashes on such a size mismatch. Some protection against the loading of 'type aliens' must be implemented before double precision Pd (and externals in particular) can be distributed as stable release, whenever that will happen. And this protection must preferably be backwards compatible, in such a way that old Pd installations from the 'single only era' can not accidentally load new double precision classes. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] preparing phasor~Co. for double precision Pd
2011/7/28 IOhannes m zmölnig zmoel...@iem.at wrote: imho, the only sensible place to do this is the actual audio backend code (s_audio_*.c) right your audio backend might support double floats (e.g. jackd is prepared for that already, though i don't known whether anybody ever used it that way). Thanks for pointing to that. Anyway some sort of galvanic separation between arrays with t_sample and arrays passed from/to audio API must be introduced, in case they need be of different (primitive) type. PortAudio does not currently support 64 bit samples, for one thing. My first concern is to hear decent sound coming out of double precision Pd, that would really make me happy for a while. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] preparing phasor~Co. for double precision Pd
On Wed, Jul 27, 2011 at 11:11 PM, Hans-Christoph Steiner h...@at.or.atwrote: I think the big question that needs to be answered before this gets included is: can this be done without majoring impacting 32-bit operation? The intention is: - Pd source code with unaltered functionality - compilable with pd floattype 'float' or 'double' - as little conditional compilation as possible - no performance loss respective to current Pd Based on test results I think it's possible to rewrite the code in such a way that single precision Pd will not be affected in any way. I still have to rewrite tabosc~ which also uses Hoeldrich's method, this will be easy. As for 64-bit floats to output, a quick hack to get things working is to just hammer samples down to 32-bits... I was looking for a suitable spot in the code to do this. First looked at dac~, but since there may be many dac~s instantiated this is not most efficient. Then I found sys_send_dacs(), where the integrated sample values are checked for max absolute value. It is however not possible to do a simple typecast here because samples are just stored back into *sys_soundin and *sys_soundout which are type t_sample. Maybe dac~ should integrate samplevalues in an intermediate vector of type t_sample. And then, in sys_send_dacs(), integrated samples could be checked, cast to float and stored into *sys_soundout vector of type float. And something similar for the input. That's what I'll try. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Tabread/write on array bigger than 16777216 points
On Wed, Jul 13, 2011 at 3:51 PM, IOhannes m zmoelnig zmoel...@iem.atwrote: the idea is to make double the standard for Pd in the future. if nobody spents time for that it will never happen. I'd like to help with this if I can (with only fragmentary knowledge of Pd core code I must say). I recall looking at the options to compile Pd with type double, but running into union tabfudge and UNITBIT32 which are used by rather central Pd objects like [osc~] and [phasor~]. I did not fully grasp the working of this clever type punning hack, but assumed it cannot be translated to type double rightaway. Is it true that this trick is crucial for computational speed of [osc~] co, and must an equivalent routine still be developed (if possible at all)? Or are there other, more important bottlenecks to solve? Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Tabread/write on array bigger than 16777216 points
On Wed, Jul 13, 2011 at 7:38 PM, IOhannes m zmoelnig zmoel...@iem.atwrote: i think this is the main showstopper right now. the type punning tricks used to be crucial (i assume), but nowadays the speed gain should be rather low (at least according to some tests we did). A double precision Pd is high on my wishlist, and if the union tabfudge thing is the main showstopper, then it's certainly worthwhile to put effort in it. I'm often running into precision issues with Pd, not only by lack of an integer type for indexes but also in the case of signal data. In some cases I write a new external instead of a patch for this reason, which is a pity. I'll do as you say, first write and test a generic alternative with straightforward implementation, then try to optimize. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] signal nan values
Andrew Hassall wrote: pd never crashes completely, the graph crashes Sorry I misunderstood you. Never seen a graph crashing. so there is no errors or crash reports. Your lpcsynthesis_tilde_perform() method is simple and you've probably checked pointer arithmetic a dozen times. Yet valgrind attributes invalid reads and writes to it. How frustrating. Pd does not crash, the invalid access is probably happening within it's allocated space. Best thing would be if you can force Pd to crash on it. Instantiate a lot of your objects, delete some of them, or close/open patch several times etc. Pd's allocated memory is not a continuous block. Under circumstances, Pd must crash on an illegal access, and you'll be pointed to the culprit code. Well this is my not-so-educated guess. I've had similar situations with my own homebrew objects. Good luck anyway. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] signal nan values
Andrew Hassall wrote: Yeah I thought it must be my code. Can't check whether all the pointer arithmetic is correct... When I cause an illegal memory access on OSX and Pd crashes on it, the crash log report gives exactly the line nr. of the offending code. Don't you get such information? Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] integrating pdlua into Pd-extended
Hello, In the original Makefile.static for pdlua it is defined: lua-5.1.3 This worked for me on OSX. Katja On Fri, Mar 18, 2011 at 7:07 PM, Claude Heiland-Allen cla...@goto10.orgwrote: Hey, On 18/03/11 17:38, Martin wrote: The error actually seems to originate in pkg-config not finding lua5.1: From my limited experience, Lua 5.1 libraries have different names all over the place, even in different GNU/Linux distros (lua51, lua5.1, lua5, lua, ...). A bit of a nightmare. pkg-config lua --libs should do it on Mac OS X/Fink. .hc Claude ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] question about building externals on Linux
Ivica Ico Bukvic wrote: I've taken a quick stab at trying to port John Gibson's spectdelay~ external from Max to Pd and got stuck at the following error: load_object: Symbol spectdelay_tilde_setup not found From the code, it seems that the extern C specification is commented out together with Max-specific code for the setup function. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
