Pd-list October 2015

pd-list@lists.iem.at

55 participants
86 discussions

nice loop~ example
by Alexandre Torres Porres 19 Oct '15

19 Oct '15

howdy, anybody got a cool patch that depends on loop~ or illustrates a nice usage of it? I find this object not very interesting and easily replaceable by just phasor~ + *~ so I just never used it cheers

2 1

Re: [PD] playing .mid files in puredata
by Dan Wilcox 19 Oct '15

19 Oct '15

Howdy all, xeq looks like a good candidate for resurrection via pd-lib-builder, so I got it building and put it on Github: https://github.com/pure-data/xeq <https://github.com/pure-data/xeq> It’s not quite working yet, but I bet a few of you could help me on that. Once it does, then we can upload builds via deken. -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> > On Apr 8, 2015, at 4:00 AM, pd-list-request(a)lists.iem.at wrote: > > From: Winfried Ritsch <ritsch(a)iem.at <mailto:ritsch@iem.at>> > Date: April 8, 2015 at 3:17:00 AM MDT > To: pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at> > Subject: Re: [PD] playing .mid files in puredata > > > thats true and sad^1 ... so I found it and uploaded it to rest ... > > https://puredata.info/community/conventions/convention04/lectures/tk_czaja/… <https://puredata.info/community/conventions/convention04/lectures/tk_czaja/…> > > ^1: since I used it quite a lot of time and had a cool structure for holding > midifiles and using many players to reference for them... (live midi > looping...) ... > > ... using seq instead for my autopianoplayer. > > mfg > winfried

2 3

Set of objects for beat-oriented timing?
by Spencer Russell 19 Oct '15

19 Oct '15

Is there a set of objects for expressing beat-relative timing? I’m thinking of a [beatclock] that sends out beat messages and a set of objects like [beatmetro], [beatdelay~], etc. that act like their ms-based counterparts but receive the beat clock and respond to tempo changes. Probably a general-pupose [beatms] that just outputs the beat period in ms for use with objects that aren’t wrapped in the library. If not I’ll probably build some, but I figured I’d check to see if the community already has something nice to solve this problem, as I’m sure it’s come up before. -s

4 3

Re: [PD] cartopol~ and poltocar~
by Jonathan Wilkes 19 Oct '15

19 Oct '15

Hi Ivica, When we discussed the threading feature before, I advocated against it since it breaks determinism. However, the Max/MSP documentation (as well as the outlet interface itself) suggests that Max's implementation is threaded, too. Why else would you need a bang to signal when it has finished reading the file, for example? Can someone test how it works in practice in Max? I'm in favor of the default behavior for the sake of backwards-compatibility within Pd. But if Max is actually threading the reads/writes, that would make this an important general feature for Max compatibility. -Jonathan On Friday, October 16, 2015 11:50 PM, Ivica Bukvic <ico(a)vt.edu> wrote: cool = coll-- Ivica Ico Bukvic, D.M.A. Associate Professor Computer Music ICAT Senior Fellow Director -- DISIS, L2Ork Virginia Tech School of Performing Arts – 0141 Blacksburg, VA 24061 (540) 231-6139 ico(a)vt.edu www.performingarts.vt.edu disis.icat.vt.edu l2ork.icat.vt.edu Ico.bukvic.netOn Oct 16, 2015 11:48 PM, "Ivica Bukvic" <ico(a)vt.edu> wrote: I am sure this has been covered on this list before--if it is not too much of a trouble where can one get the new version of cyclone?Also, there are some improvements on pd-l2ork side of things that I've implemented that may detract from Max behavior but also offers other benefits. For instance, coll object can be threaded and as such allows loading of large files without dropping samples, albeit at the expense of determinacy, so one in these cases must rely on outputting done loading bang signal before working with the cool object. This option is fully backwards compatible and the default behavior is non-threaded. It would be great if we could have those merged so that we don't have to maintain two separate versions of the cyclone library.Best,-- Ivica Ico Bukvic, D.M.A. Associate Professor Computer Music ICAT Senior Fellow Director -- DISIS, L2Ork Virginia Tech School of Performing Arts – 0141 Blacksburg, VA 24061 (540) 231-6139 ico(a)vt.edu www.performingarts.vt.edu disis.icat.vt.edu l2ork.icat.vt.edu Ico.bukvic.netthis has been corrected in the new cyclone library actually, both cartopol~ and poltocar~ were "wrong" in the same way, but for extended 0.42 only poltocar~ was corrected, this incomplete fix ended up ruining spectral processing that was actually working before that. get the new cyclone, many objects are being corrected cheers 2015-10-16 18:14 GMT-03:00 Gilberto Agostinho via Pd-list <pd-list(a)lists.iem.at>: Just a little update: the problem is with [cartopol~], its rightmost outlet is outputting the correct value multiplied by -1. On 16/10/15 22:55, Gilberto Agostinho wrote: Hello, I believe I found a bug with the objects [cartopol~] and [poltocar~]. Basically, if I would connect both outlets of [cartopol~] to the inlets of [poltocar~], I would expect to receive the same values as I would input. The problem is that the output of the second outlet of [poltocar~] is multiplied by -1! I tested this with both Pd 0.46.5 and pd-extended 0.43.4 (and this bug isn't present in Pd-l2Ork). Here is an image of the problem: http://s1.postimg.org/bs79w4d5b/Screenshot_from_2015_10_16_22_50_23.png Is this a known bug? Cheers, Gilberto _______________________________________________ Pd-list(a)lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list(a)lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list(a)lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

4 13

[PD-announce] Morphist
by chdh 19 Oct '15

19 Oct '15

_______________________________________________ Pd-announce mailing list Pd-announce(a)lists.iem.at http://lists.puredata.info/listinfo/pd-announce

1 0

[PD-announce] Audio Technology Position at American University
by William Brent 19 Oct '15

19 Oct '15

Hi Pd-list. Please see this job opportunity below. Application review will begin Oct 19. The Department of Performing Arts in the College of Arts and Sciences at American University invites applications for a full-time, tenure-track position in Audio Technology at the rank of Assistant Professor beginning August 1, 2016. Applicants should hold a terminal degree in an audio-related field or anticipate completion by August 2016. Candidates should be effective teachers and must be strongly committed to excellence in scholarly research. We welcome applications from candidates engaged in high-quality scholarship in the broad field of audio technology and are particularly interested in candidates with any of the following areas of specialization: acoustics, cognition/perception, electronics, game audio, spatialized audio, and audio software/hardware design. Teaching specialization in any of the above areas as well as live sound or broadcast audio is preferred, though all instructional areas will be considered. In addition to scholarship and teaching, responsibilities will include participation in department, school and university activities. Salary and benefits are competitive. Review of applications will begin on October 19, 2015 and will continue until the position is filled. Please submit applications via: apply.interfolio.com/31531. Include a letter of application, curriculum vitae, and three letters of recommendation. Additional materials will be requested at a later date. Please contact Richard Streeks, Faculty Coordinator, streeks(a)american.edu if you have any questions. American University is an equal opportunity, affirmative action institution that operates in compliance with applicable laws and regulations. The university does not discriminate on the basis of race, color, national origin, religion, sex (including pregnancy), age, sexual orientation, disability, marital status, personal appearance, gender identity and expression, family responsibilities, political affiliation, source of income, veteran status, an individuals genetic information or any other bases under federal or local laws (collectively Protected Bases) in its programs and activities. American University is a tobacco and smoke free campus. -- William Brent www.williambrent.com “Great minds flock together” Conflations: conversational idiom for the 21st century www.conflations.com _______________________________________________ Pd-announce mailing list Pd-announce(a)lists.iem.at http://lists.puredata.info/listinfo/pd-announce

1 0

How does vline~ work under the hood?
by i go bananas 18 Oct '15

18 Oct '15

I want to recreate the timing accuracy of vline~ in a c++ project, and there's something that i can't figure out exactly - how does it act, seemingly outside of the block construct, to get its accuracy? in the source code, there is a calculation for elapsed logical time, and i assume that has something to do with it? if i make a vline~ from 0 to 1, over 10ms, does this mean that it actually doesn't START right on 0, but rather starts at a slightly offset value to compensate for the block boundary? any help would be appreciated!

6 35

cartopol~ and poltocar~
by Gilberto Agostinho 17 Oct '15

17 Oct '15

Hello, I believe I found a bug with the objects [cartopol~] and [poltocar~]. Basically, if I would connect both outlets of [cartopol~] to the inlets of [poltocar~], I would expect to receive the same values as I would input. The problem is that the output of the second outlet of [poltocar~] is multiplied by -1! I tested this with both Pd 0.46.5 and pd-extended 0.43.4 (and this bug isn't present in Pd-l2Ork). Here is an image of the problem: http://s1.postimg.org/bs79w4d5b/Screenshot_from_2015_10_16_22_50_23.png Is this a known bug? Cheers, Gilberto

3 5

Re: [PD] fft~ bug in Pd-0.46-7-64bit.app on OSX
by Dan Wilcox 17 Oct '15

17 Oct '15

“Execution order” indeed. -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> > On Oct 16, 2015, at 4:54 PM, pd-list-request(a)lists.iem.at wrote: > > From: Jonathan Wilkes <jancsika(a)yahoo.com <mailto:jancsika@yahoo.com>> > Date: October 16, 2015 at 4:06:06 PM MDT > To: Matt Barber <brbrofsvl(a)gmail.com <mailto:brbrofsvl@gmail.com>>, Jaime E Oliver <jaime.oliver2(a)gmail.com <mailto:jaime.oliver2@gmail.com>> > Cc: Pd-List <pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>> > Subject: Re: [PD] fft~ bug in Pd-0.46-7-64bit.app on OSX > > > Is there something like a real-life [trigger] you use to keep track of their > ordering? > > -Jonathan >

3 2

fft~ bug in Pd-0.46-7-64bit.app on OSX
by Matt Barber 17 Oct '15

17 Oct '15

Hi list, There's either a major bug in the [fft~] objects in Pd-0.46.7 (64bit OSX) or I'm going crazy. I'd love to see if others can reproduce it. Basically, for [block~] sizes less than 32 bits, [fft~] doesn't perform -- it just passes the signal through unchanged. [ifft~] does the same. The [rfft~]-[rifft~] is a little more complicated -- it passes signal through but zeroes out the last N/2 for [block~] sizes less than 64. See the attached patch, which only shows [fft~]. The saved contents of the tables on opening are the results for [block~ 8] on my machine, for quarter-nyquist at 44100. I've never seen this before in other versions of Pd. Anyone else get this behavior? Matt

4 5

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list October 2015