Hi dear pd freaks,
I'm currently using [env~] for measurement purpose (room's sound
monitoring and soundfiles analysis) and I have a few questions/remarks
...that unfortunately may have already been discussed here (I have
been unsubscribed from the list since a couple of years).
However :
1)
Just noticed : the [env~] help patch (from PDDP) states that default
analysis window is 1024 samples, while it links to Miller's example
C07.envelope.follower.pd where you can read that the default window is
256 samples.
2)
AFAIK there is no way to dynamically (message) change the analysis
window's size, at least without dynamic patching.. what I "painfully"
managed to do (see attached patch "ph_env~.pd").
Ah, I can see on sourceforge that it is a request open since 2012...
http://sourceforge.net/p/pure-data/feature-requests/109/
3)
Last but not least, the question I can't answer myself !
When using multiple [env~] it isn't very clear for me which one will
output first.
So it confuses me when I try to do very simple things like comparing
(difference) two signals' amplitude : doing a substraction requires to
input the [- ] object in correct order (right inlet before left's).
While doing it the wrong order may seem to work, I realized that in
fact I was comparing two different windows.
The actual order of output between different [env~] seems to be
related to the objects' order of creation. I think that order of
creation is a trouble since you cannot "read" it in the patch, so it
isn't "the diagram is the program" anymore. Moreover, as far as i can
deduce from what i experimented empirically (means : i'm not sure at
all) the first to output is the last that was created.
My experiments with order can be found in "order_env~.pd" attached file.
Finally, maybe all this mess is just me not being very clear with how
message/DSP are scheluded/interfaced... but I feel that [snapshot~] is
way more easy to understand and control, since it outputs value "on
demand" (bang) and order can be easily stated with [trigger]. I think
i'd feel much more comfortable with a kind of [env~] object that
computes the enveloppe of the last N audio blocks or last N samples,
"on demand", when triggered by a bang.
Maybe someone will answer me that I'm really confused and that my
problems are false problems... In case, I'd be glad to be taught the
right way !
Cheers,
Raphaël
who in their right mind creates such an object?
haha, just kidding.
just finished watching Miller's pd lectures 19 and 20, the online videos.
they are amazing. the filter section of 19 blew my mind.
I also agree. Security issues aside, An (auto) downloader would be a *nice to have* and not a *requirement*. I see an option like that *only* after the requisite base of external builds, repositories, external listing info/site are in place. After that we could maybe think about a package management deal, but that’s *non trivial* to say the least. Sure it works in large projects like Debian but only after years of work an maintenance by a large number of people.
People have managed to download and install Max externals for years now. The best/easiest solution is a default folder search path like Pd-extended’s "pd-externals” folder in the user home directory. Then you just tell people to drop the externals in there and have an optional setting to automatically add all subfolders to the search path. This is what I do in PdParty so it’s pretty easy to add stuff. It could work imilar to how libdir does in extended. Power users could turn off the auto search path adding and stick with loading by name, etc.
--------
Dan Wilcox
@danomatika
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
> On Dec 18, 2014, at 3:37 PM, pd-list-request(a)lists.iem.at wrote:
>
> From: Fred Jan Kraan <fjkraan(a)xs4all.nl <mailto:fjkraan@xs4all.nl>>
> To: pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>
> Date: December 18, 2014 at 3:02:36 PM EST
> Subject: Re: [PD] [Bulk] Extending Vanilla (was Cyclone help patches & issue list)
>
>
> On 2014-12-18 20:34, IOhannes m zmölnig wrote:
>> On 12/18/2014 08:16 PM, Samuel Burt wrote:
>>> 1. Opening a patch with [import cyclone] would automatically download the
>>
>> i *strongly* oppose to anything that automatically connects to the
>> internet and fetches or submits data.
>
> And the Pd-community currently does not have the resources to build
> something that is similar or more advanced than the Debian distribution
> system and preferably be cross platform.
>>
>> mgfdsr
>> IOhannes
>>
> Greetings,
>
> Fred Jan
Hello, I'm opening a new thread about the new direction of discussion with
a proper subject title. Perhaps this will call the attention of other
readers.
I particularly think this is of major interest to everyone. We're
discussing new ways of using the libraries in Pd Extended into Pd Vanilla,
and even a way to bring some of the Pd-extended UI changes into vanilla.
Something Miller brought up in the thread was "*Just FYI…. Joe Deken
of newblankets.org <http://newblankets.org/> is considering making a
repository of external objects compatible with Pd vanilla. I think almost
all the*
*objects in Pd extended will work with vanilla (and if I find out
what specific changes vanilla would need to allow the others, I'd be happy
to try to provide them). It seems like maintaining compiled versions of
the **libs is an easier thing to do than maintaining all of Pd Extended*."
So, anyone else care to share their two cents?
cheers
2014-12-17 1:05 GMT-02:00 Jonathan Wilkes via Pd-list <pd-list(a)lists.iem.at>
:
>
> Well, you can peruse the tracker's open patches to get a sense of whether
> you can (or if it's worth your time to try). Keep in mind the Pd-l2ork gui
> prefs code started out as a patch specifically written as a clean, small
> patch to get into Vanilla/Extended.
>
> -Jonathan
>
>
> On Tuesday, December 16, 2014 6:04 PM, Dan Wilcox <danomatika(a)gmail.com>
> wrote:
>
>
> Sorry, I didn;t mean to sound like I'm griping. The nature of the question
> was more "if we apply clean, small patches to vanilla, could we get some of
> Han's updates in so they aren't lost to non Pd-l2ork users". I'm in the
> middle of writing my thesis right now, but getting into real Pd development
> again is on my list when I'm finally done with it.
>
> On Tue, Dec 16, 2014 at 5:59 PM, Jonathan Wilkes <jancsika(a)yahoo.com>
> wrote:
>
> On 12/16/2014 03:12 PM, Dan Wilcox wrote:
>
> I like how I explicitly asked to not hear that "Pd-l2ork has that" and
> yet that's the response I got. I already knew this anyway from the sample
> screenshots you were posting when you were implementing it. (Looks great
> BTW)
>
>
> Yeah, I know, it was 100% willful snark on my part. It's kind of like you
> were asking, "Is there a way to do X, while satisfying my irrational desire
> to ignore a working solution by someone who likely already did X?"
>
> Anyway, did you look at the code? It's done in tcl/tk, and it does not
> depend on tkpath. So if you don't want to duplicate all the work I already
> did, you can fairly easily port that back to Pd Vanilla. There might be a
> few API differences in accessing the audio backend, but there are small and
> I don't mind helping make those changes.
>
> Also, I specifically did everything in tcl/tk so that the patch would be
> as simple as possible. It shouldn't even require a recompile. Now, I
> haven't looked at Ivica's changes that added persistence. But all versions
> of Pd have the same prefs-saving code so that shouldn't be difficult,
> either.
>
>
> Also, if you didn't know, why respond? :P
>
>
> Because the answer to your question ultimately depends on whether what you
> come up with fits the unspoken yet stringent HIG standards imposed by
> Miller's Pd.
>
> But that doesn't mean that code which does _exactly_ what you're asking
> about isn't relevant to your question.
>
> -Jonathan
>
>
> On 12/15/2014 06:21 PM, Dan Wilcox wrote:
>
> If that does become a real scenario, I hope we can find a way to bring
> some of the Pd-extended UI changes into vanilla, such as the pixel perfect
> sizing across platforms, an option for the extended coloring (graytones)
> etc. Before anyone says “Pd-Lork has that”, I’m just wondering if it’s
> feasible to bring in some of the work Hans did after the gui cleanup which
> is already in vanilla.
>
>
> In answer to your question: I don't know.
>
> Having answered that...
>
> Pd-l2ork has gui theme presets for Vanilla, Inverted Vanilla, Pd-extended,
> Commodore 64, Strongbad's Compy, and a few others. There's also an
> interface to make a custom theme-- I didn't make it persistent but I think
> Ivica added that ability.
>
> -Jonathan
>
>
> --
> Dan Wilcox
> danomatika.com
> robotcowboy.com
>
>
>
>
> --
> Dan Wilcox
> danomatika.com
> robotcowboy.com
>
>
>
> _______________________________________________
> Pd-list(a)lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
howdy, some libraries have a "flatspace" designation for some objects, like
"zexy flatspace", "cyclone flatspace", "iemlib flatspace"... I don't really
get it.
What's the deal with it?
thanks
Hi,
While maintaining lots of patches, one thinks of automation. To
understand the pd-patch better and exercise my Tcl-coding, I made a pd
patch parser. Currently it only lists the objects with their number and
a number for the (sub-)patch they are in.
The plan was to make a streaming pd-editor to remove objects, which
fixes the connections too. For now, it just shows you an augumented view
of the back side of your patch ;-).
It can also be found at:
http://fjkraan.home.xs4all.nl/digaud/puredata/pdParse.tcl
Fred Jan
hi all
is there some way to run PD 32 bits on a Ubuntu 64 bits system?
sorry if this is stupid question but after a quick search I could not
see any recent answer.
thanks
enrike
Has anyone else started using these wonderful tools?
http://www.proceso-pd.blogspot.com.ar
I love them, they are making some awesome minimal electronic on my computer. I have been ONLY using the tools included thereby limiting myself to just those tools and seeing what i come up with, really wonderful and bravo!
Patrick Pagano B.S, M.F.A
Audio and Projection Design Faculty
Digital Worlds Institute
University of Florida, USA
(352)294-2020
I haven’t seen this. Do you have an example that does it?
Can you compare the same patch with my demo build of Pd 0.46 with retina screen support: Pd-0.46-0-64bit-retina.app.zip <http://docs.danomatika.com/Pd-0.46-0-64bit-retina.app.zip>
--------
Dan Wilcox
@danomatika
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
> On Dec 17, 2014, at 4:12 AM, pd-list-request(a)lists.iem.at wrote:
>
> From: Philip Stone <pkstone(a)ucdavis.edu <mailto:pkstone@ucdavis.edu>>
> To: PD list <pd-list(a)iem.at <mailto:pd-list@iem.at>>
> Date: December 16, 2014 at 6:20:19 PM EST
> Subject: [PD] Mac Retina display - graphics glitching?
>
>
> Upon getting a new 13” Retina Macbook, I have started to notice glitching in the PD UI. I thought this might signal a need to upgrade to Pd-extended 0.43.4, so I did, but this did not fix the glitching. Usually, the glitching manifests as a flickering GUI slider, but sometimes, a whole squarish section of the screen flickers briefly.
>
> It’s not disabling, but it’s very distracting to see the screen flashing out of the corner of my eye.
>
> Configuration:
>
> MacBook Pro (Retina, 13-inch, Mid 2014)
> Pd Version: 0.43.4-extended
> Tcl Version: 8.5.11
>
> I haven’t searched the bugs list yet; I’m just wondering if anybody else has noticed this?
>
>
> Phil Stone
> UC Davis
Hi Gavin!
On 09/12/14 19:27, Gavin wrote:
> Is it ok to email you about this or would you prefer to keep it to the
> forums?
I hope you don't mind me CC'ing this to the Pd-list.
I'm happy you emailed about this because it is exactly what I have been
working on lately when I find spare time.
> I'm a bit confused as to the network options with pddroidparty.
> There is netro which seems to be based on netsend and x-netreceive but
> also droidnetreceive and also netreceive!
> Which is the recommended or latest one?
The native netsend and netreceive now work in the version of Pd that
ships with PdDroidParty. The other libraries are deprecated. Sorry for
the confusion - there was a long standing bug with netreceive not
working in libpd that is now resolved. x-netreceive was just my way of
commenting out netreceive - you can change it back to netreceive and
remove the top level droidnetreceive hack object and netro should just
work again.
Netro is an abstraction for doing timing synchronisation of Pd patches
that runs on top of netreceive. I haven't updated it for a long time
because I've been working on something that does the job better:
http://github.com/chr15m/SyncJams/
SyncJams uses OSC underneath and so it can interoperate more widely with
other software. There is also a Python implementation and I am hoping
for implementations in other languages (especially Supercollider) down
the track. Patches welcome!
SyncJams provides a way to not only sync metronomes during live
performance but also a sort of distributed hash table ("set-state")
where everybody involved in a jam can share state information like
controller position, song key, etc. There is also a generic conduit for
in-time events ("message") to be propagated in order such as drum beat
hits from a live drummer.
I've been testing on Android, and latency aside things are working
pretty smoothly now.
> Also is there anyway to debug/print to a console on a phone?
If you use Pd's print object you can then use `adb logcat` to see what
comes out - you'll need to have your phone in debugging mode and
connected via USB or over TCP to adb.
> I'm hoping to guesstimate latency by calculating the time it takes to
> send data from one device to another and back and sync phasors on
> separate devices.
>
> Have you tried this?
So latency is the exact problem I am tackling at the moment.
After speaking to Peter Brinkmann, the resident Android audio expert,
the outlook is as abysmal as ever. The way audio is implemented on
Android means you can't ever really know with 100% certainty how long it
takes between a software event and the speaker actually emitting the
triggered sound.
My approach, which is hopefully "good enough" is similar to what you
suggest, except that a single device can send a signal to its own
microphone to measure the round trip time. Hopefully half of the round
trip time will give the approximate output latency. This is what the
android-latency-tester patch did and I will probably use that same
method (with the bonk~ object).
<http://puredata.info/docs/AndroidLatency/>
I tested a FFT based cross correlation approach to detect the
same-device latency, but it wasn't really robust enough. That is in the
SyncJams repository if you want to take a look. Maybe I did something
wrong though as my DSP math is not very strong.
There is also Raph Levien's audio buffer size tool:
https://play.google.com/store/apps/details?id=com.levien.audiobuffersize
Which uploads its results for different devices:
http://audiobuffersize.appspot.com/
Code:
https://code.google.com/p/high-performance-audio/source/browse/audio-buffer…
In the end I think the approach on Android is going to be:
* Alert the user the first time they run the patch that latency needs
to be tested.
* "Please turn up your speakers while we run the test."
* Collect the timing data using bonk~ or FFT cross correlation or
whatever and write it to disk.
* Everybody who makes an Android Pd app can use the same filename,
location, and format for the data (/sdcard/Pd/latency-test.txt) so
hopefully it only has to be done once.
* Use the values in that file to compensate for latency.
* Provide a menu option for the user to re-run the compensation if they
feel latency is getting out of hand.
> PS One more thing - where can I get x-netreceive so I can install it on
> my laptop. Is it the same as xnetreceive?
x-netreceive is not a real object - it's what I used to comment out the
existing netreceive object in netro when that wasn't working under
PdDroidParty. What you can do is replace it with netreceive instead, and
remove droidnetreceive entirely. Things should work after that.
Let us know how you go!
Cheers,
Chris.
--
http://mccormick.cx/