Pd-list December 2015

pd-list@lists.iem.at

56 participants
94 discussions

PD "native" scripting language (was: Re: Pd-list Digest, Vol 129, Issue 26
by William Huston 09 Dec '15

09 Dec '15

On Monday, December 7, 2015, Dan Wilcox <danomatika(a)gmail.com> wrote: > In 2016 it will be *trivial* to install a scripting language external such as pdlua via the deken plugin which will be included in the next Pd vanilla version release … I will be interested in seeing how this works. Since Perl is my favorite, I was just thinking today about something like "mod_perl" for Apache, but for PD-- a persistent Perl program which PD can pass of certain tasks to. Things like complex data structures (associative arrays, or multi-dimensional arrays) and regular expression parsing I find is so much easier in Perl (but I'm only about 1.5 years into PD, so there are likely many cool tricks I haven't learned yet). I'm thinking about implementing my Chord Library gizmo in Perl, but I don't want to pay for the overhead of invoking the Perl compiler with each [shell]. For now, I'm considering just starting my Perl agent as a daemon, and communicating to PD via local sockets... > -------- > Dan Wilcox > @danomatika > danomatika.com > robotcowboy.com > > On Dec 7, 2015, at 2:23 PM, pd-list-request(a)lists.iem.at wrote: > From: Lorenzo Sutton <lorenzofsutton(a)gmail.com> > Date: December 7, 2015 at 2:23:40 PM MST > To: pd-list(a)lists.iem.at > Subject: Re: [PD] get filenames from directory > > > On 07/12/15 17:26, Jonathan Wilkes via Pd-list wrote: > > It's not possible with Vanilla objects. > > In 2016 it would really be nice for Pd *Vanilla* to allow *natively* the use of some scripting language. My personal fav would be Python, but I'd be happy with anything really... > > After the heated debates about luscious beizer curved chords and gradients in 2013, I this is still miss this feature more than any sexy GUI - :-) > > Lorenzo. > -- -- May you, and all beings be happy and free from suffering :) -- ancient Buddhist Prayer (Metta)

3 2

get filenames from directory
by Simon Iten 09 Dec '15

09 Dec '15

what would be an appropriate way to get all filenames out of a directory in pd-vanilla? i have only seen very old posts about this, they all use pd-extended. is there any recent object/external that does this? it could be nice if openpanel could also open a directory and output all the filenames... alternatively is there a way to just read all the files from a directory one after the other? cheers

4 12

pd-l2ork git updates -- looking for testers
by Ivica Ico Bukvic 09 Dec '15

09 Dec '15

A couple of recent updates to pd-l2ork beg for more testing and we could really use your help in vetting these before making a next official release. Most notably, the new git version includes: *new legacy mode (invoked using the -legacy flag at pd-l2ork startup) that repositiones all iemgui objects to match their old (albeit inconsistent) locations. This should make it effectively possible to open old patches and make them look nearly identical on pd-l2ork. The remaining caveat is that pd-l2ork includes object labels when calculating their bounding box and therefore there are still inconsistencies in the way how for instance gatoms and iemgui objects are rendered (or not rendered) inside graph-on-parent (GOP) subpatcher based on whether they truly fit inside GOP or not. *Ability to use $0 in messages and having those automatically converted into canvas instance (mixed messages including $0 are also possible). *Ability to use $n and #n anywhere in the labels, sends, and receives in gatoms and iemgui objects, including ability to use multiple instances of them (e.g. $0-blah-$1 or #0#1a etc.). Also ability to use # as a character inside these same entries (e.g. # alone or followed by a non-digit will remain unchanged, whereas #0 will be resolved into canvas instance and #1 into first patcher creation argument) All of these should be implemented retaining backwards compatibility. So, at this point I am looking for any possible regressions or observed major performance impact due to newly added features. Your assistance in this effort is most appreciated. NB: We are working on a 64-bit build for Ubuntu 14.04 which we will share with those interested in providing feedback. Given this is a development version, we will not provide 32-bit builds or debs for other distros and would prefer not to widely publicize its availability as we are not sure yet if the newly implemented features are regression free. Ideally, those interested in testing should build their own version, which should be a simple 3-step process, including installing the new version. If all goes well, a new version with this and other additions should go live sometime later this month. Best, -- Ivica Ico Bukvic, D.M.A. Associate Professor Creative Technologies in Music ICAT Senior Fellow Director -- DISIS, L2Ork Virginia Tech School of Performing Arts – 0141 Blacksburg, VA 24061 (540) 231-6139 www.performingarts.vt.edu disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net

2 2

Cyclone issues update
by Fred Jan Kraan 09 Dec '15

09 Dec '15

Hi List, Finally a set of changes made it to a workable state: - average~: Created an average2~ to support a signal outlet for Max compatibility and retain backward cyclone compatibility in average~. - frameaccum~: Added a wrap option. - coll: Added threaded load/save option from L2ork by Ivica Ico Bukvic. - Scope~: Improved resize behaviour. Added a resize message to support pixel accurate resize. - all signal objects: Prevent crash Pd with [dsp( message. The intention is to test this on multiple platforms and create deken compliant binary distributions as version 0.2 beta1. The current state of the code can be found at: https://github.com/electrickery/pd-cyclone. Note the coll and average2~ code are currently in topic specific branches. Fred Jan

4 6

Moving Sum object?
by Alexandre Torres Porres 08 Dec '15

08 Dec '15

Talking about averages I wonder if we have an object that sums (in a moving average fashion) a series of samples cheers

3 20

Re: [PD] Pd-list Digest, Vol 129, Issue 26
by Dan Wilcox 07 Dec '15

07 Dec '15

In 2016 it will be *trivial* to install a scripting language external such as pdlua via the deken plugin which will be included in the next Pd vanilla version release … -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> > On Dec 7, 2015, at 2:23 PM, pd-list-request(a)lists.iem.at wrote: > > From: Lorenzo Sutton <lorenzofsutton(a)gmail.com <mailto:lorenzofsutton@gmail.com>> > Date: December 7, 2015 at 2:23:40 PM MST > To: pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at> > Subject: Re: [PD] get filenames from directory > > > On 07/12/15 17:26, Jonathan Wilkes via Pd-list wrote: >> It's not possible with Vanilla objects. > > In 2016 it would really be nice for Pd *Vanilla* to allow *natively* the use of some scripting language. My personal fav would be Python, but I'd be happy with anything really... > > After the heated debates about luscious beizer curved chords and gradients in 2013, I this is still miss this feature more than any sexy GUI - :-) > > Lorenzo.

1 0

Re: [PD] comport rxerrors on W10
by rolfm＠dds.nl 07 Dec '15

07 Dec '15

comport.c(422) : error C2065: 'nr' : undeclared identifier trying to compile comport with Visual Studio 2008 i get the above error. this is without the diff file ( i don't know yet how to use it) i must confess it's quite an adventure to try to compile (comport) with very little experience. where to find the actual source? how to download in the correct form? which program to use fro compiling and how to get it? where to find the right version of the 'missing' m_pd.h? the puredata website is actually not a great help in that. without google i would still be searching for things. rolf

2 5

[PD-announce] Software Developer Position for MUSICOLL ANR Project
by Pierre Guillot 07 Dec '15

07 Dec '15

[apologies for multiple postings] Job Advertisement: Software Developer for MUSICOLL ANR Project 8 month contract starting on February, 1st, 2016 Associating the Computer Science and Musical Creation Research Centre (CICM) / MSH Paris Nord USR 3258 and the OhmForce company, specialized in collaborative digital audio, the MUSICOLL project (2016-2018), funded by French National Research Agency proposes to redesign musical practices of real-time in a collaborative and nomadic environment. Over a first phase, this project aims at the specification and development of a C++ software prototype using the JUCE framework. It should enable several creators to work simultaneously on the design of sound processes hosted online. In that perspective, we are seeking a software developer that will work with two Ph.D. candidates / developers and two researchers from CICM. Missions - involved in the development of the software kernel. - involved in the development of user graphic interface. Training level: Engineer or Master 2 in software engineering if possible with a specialization in digital audio signal processing. Required experience: 2 years. Required skills - mastery of C++ language (standard library from C++11). - mastery of versioning tools (Git) - mastery of continuous integration tools Desired skills - knowledge of the JUCE framework (http://www.juce.com/) - knowledge in digital audio signal processing. Complementary skills: practice of such visual programming softwares as Pure Data or Max. Other skills: excellent editorial skills in English and French. Ability to work in teams and communicate. Terms and conditions: - Beginning : february, 1st, 2016. - Localization : MSH-Paris-Nord, 20 avenue George Sand - 93210 Saint-Denis. Subway station: Front Populaire (line 12) - Salary on the basis of a Research Engineer Contractor 1st grade of CNRS (National Centre for Scientific Research) equivalent to a gross annual salary of 29386 euros. - 8 month contract at fulltime. Contact: If you are interested, send us your curriculum vitae, a motivation letter and a portfolio of your previous realisations at cicm.mshparisnord(a)gmail.com CICM is localized between the Université Paris VIII <http://www-artweb.univ-paris8.fr/spip.php?rubrique336> and the Maison des Sciences de l'Homme Paris Nord <http://www.mshparisnord.org/>. CICM is linked to the équipe d'accueil MUSIDANSE n° 1572 "Esthétique, musicologie et créations musicales" <http://www.musique.univ-paris8.fr/>, Ecole Doctorale "Esthétique, Sciences et Technologies des Arts » <http://www.edesta.univ-paris8.fr/> at the Université Paris VIII <http://www-artweb.univ-paris8.fr/spip.php?rubrique336>. __________________________ Offre d’emploi : Développeur logiciel pour le projet ANR MUSICOLL CDD de 8 mois à partir du 1er février 2016 Associant le Centre de Recherche en Informatique et Création Musicale (CICM) / MSH Paris Nord USR 3258 et la PME OhmForce, spécialisée dans l’audionumérique collaboratif, le projet ANR MUSICOLL (2016-2018) propose de repenser la pratique musicale du temps-réel dans un environnement collaboratif et nomade. Dans un premier temps, le projet vise la spécification et le développement d’une maquette logicielle C++ utilisant le framework JUCE. Elle permettra à plusieurs créateurs de travailler simultanément à l’élaboration de traitements musicaux temps-réel hébergés en ligne. Dans cette perspective, nous cherchons un développeur informatique qui travaillera au sein d’une équipe composée de deux doctorants/développeurs et de deux chercheurs du CICM. Missions - Participation au développement du noyau logiciel. - Participation au développement de l’interface graphique utilisateur. Niveau de formation : Ingénieur ou titulaire d’un Master (Bac+5) en ingénierie informatique si possible avec une spécialisation en traitement du signal audionumérique. Expérience requise : 2 ans. Compétences requises - Maîtrise du langage C++ (bibliothèque standard à partir du C++11). - Maîtrise des outils de contrôle de version (Git) - Maîtrise des outils d’intégration continue Compétences souhaitées - Connaissance du framework JUCE (http://www.juce.com/) - Connaissances en traitement du signal audionumérique. Compétences complémentaires : Pratique des logiciels de programmation visuelle tels que Pure Data ou Max. Autres compétences : Excellentes compétences rédactionnelles. Lecture et écriture de l'anglais. Aptitude à travailler en équipe et à communiquer. Modalités - Début : 1er février 2016 - Localisation : MSH-Paris-Nord, 20 avenue George Sand - 93210 Saint-Denis, Métro : Front Populaire (ligne 12) - Rémunération sur la base d’un profil d’Ingénieur de Recherche contractuel 1er échelon CNRS correspondant à un salaire brut annuel de 29386 euros. - CDD de 8 mois à temps plein. Contact Si vous êtes intéressé(e), envoyez nous un CV, une lettre de motivation ainsi qu’un portfolio de vos réalisations à l’adresse : cicm.mshparisnord(a)gmail.com Le CICM est une équipe bi-localisée entre l'Université Paris VIII <http://www-artweb.univ-paris8.fr/spip.php?rubrique336> et la Maison des Sciences de l'Homme Paris Nord <http://www.mshparisnord.org/>. Le CICM est rattaché à l'équipe d'accueil MUSIDANSE n° 1572 "Esthétique, musicologie et créations musicales" <http://www.musique.univ-paris8.fr/>, Ecole Doctorale "Esthétique, Sciences et Technologies des Arts" <http://www.edesta.univ-paris8.fr/> de l'Université Paris VIII <http://www-artweb.univ-paris8.fr/spip.php?rubrique336>. _______________________________________________ Pd-announce mailing list Pd-announce(a)lists.iem.at http://lists.puredata.info/listinfo/pd-announce

1 0

[gemhead]s vs. [separator]
by João Pais 07 Dec '15

07 Dec '15

Hello list, I don't work with GEM so regularly, so I had a question regarding independent processing chains. I'm showing different [shpere]s, and wanted to do individual transformations on each, such as [color] and [translateXYZ]. Until now I used an individual [gemhead] for each [sphere], but I just learned that it can also be done using one common [gemhead] and [separator]s instead. I would like to learn, what are the pros and cons of each solution? Which solution is more efficient and for which reasons? Plus: [color] and [colorRBG] seem to have the same function. Besides the extra inputs, is there any difference/advantage in one object instead of the other? Best, jmmmp

3 4

Fwd: chord libraries?
by William Huston 07 Dec '15

07 Dec '15

Matt suggested I forward this side discussion (and attachment) to the list. N.B., Matt is referring by number to the list of 55 intervals I identified in my original, quoted below. However, it was an HTML list, and the numbering got munched during quoting. Sorry if that makes this slightly unclear. --BH ---------- Forwarded message ---------- From: Matt Barber <brbrofsvl(a)gmail.com> Date: Monday, November 2, 2015 Subject: chord libraries? To: William Huston <williamahuston(a)gmail.com> We also eliminate transpositions, so in this case 55 is the same chord as 1, 18 and 12 are the same, and so forth. If we eliminate all transpositions and inversions, we end up with 12 trichords: 012* 013 014 015 016 024* 025 026 027* 036* 037 048* I marked the 5 that are self-inversional with a star. They're all "musical," but again it depends on the type of music you're looking at. All 19 trichords (eliminating transpositions and respacing) have been in use as simultaneities since the late 1800s, but some more than others. 012 didn't get a huge foothold until the first decade or two of the 20th century. See the attached; it does eliminate inversions, but it wouldn't be that hard to make that a user preference. [list-setclass] outputs the normal form as I described above, and the interval-vector one outputs a catalog of the chromatic intervals contained in the chord (eliminating unisons, octaves and inversions). In mod 12 there are 6 chromatic intervals, counting minor seconds and major sevenths as the same -- the output just gives you the number of each interval in the chord from 1 to 6 (or whatever if you choose a different modulus). Matt PS -- if you like, you can bump this response up to the list. On Mon, Nov 2, 2015 at 12:28 PM, William Huston <williamahuston(a)gmail.com> wrote: > > Thanks Matt. Yes interested. > > FTR, if we do not eliminate inversions, I count 55 3-tone chords in 12TET: > > 111000000000 > 110100000000 > 110010000000 > 110001000000 > 110000100000 > 110000010000 > 110000001000 > 110000000100 > 110000000010 > 110000000001 > 101100000000 > 101010000000 > 101001000000 > 101000100000 > 101000010000 > 101000001000 > 101000000100 > 101000000010 > 101000000001 > 100110000000 > 100101000000 > 100100100000 > 100100010000 > 100100001000 > 100100000100 > 100100000010 > 100100000001 > 100011000000 > 100010100000 > 100010010000 > 100010001000 > 100010000100 > 100010000010 > 100010000001 > 100001100000 > 100001010000 > 100001001000 > 100001000100 > 100001000010 > 100001000001 > 100000110000 > 100000101000 > 100000100100 > 100000100010 > 100000100001 > 100000011000 > 100000010100 > 100000010010 > 100000010001 > 100000001100 > 100000001010 > 100000001001 > 100000000110 > 100000000101 > 100000000011 > > But roughly 2/3's are inversions, so if we exclude inversions as being the same chord, then yes we get 55*.3333 =~ 19. I'm guessing at least one of these is an inversion of itself which is why 55 is not evenly divisible by 3. > > Anyway, I'm not sure how many of these are really musical. I would think of those 19, only about 8-10 are commonly used. > > Thanks, interested in whatever you have :) > > BH > -- -- May you, and all beings be happy and free from suffering :) -- ancient Buddhist Prayer (Metta)

4 7

← Newer
1
2
3
4
5
6
7
8
9
10
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 December 2015