Pd-list June 2017

pd-list@lists.iem.at

57 participants
78 discussions

simulating grid, GEM and a few questions
by Pagano, Patrick 12 Jun '17

12 Jun '17

Hello I am using vanilla nowadays and i was wondering if someone has arrived at an elegant way of simulating the X/Y control of the grid object that used to reside in unauthorized? I would like to get at least that smooth blend of x/y with one knob/control and i am curious if others have made something to replace it or have an abs that can simulate what i was sharing Also is it possible to run GEM via vanilla on a mac? I'm running Pd 0.47.1 with osx 10.11.6 after grabbing it with deken it still does not work so i am wondering if there is a stash of binaries for it somewhere? Thank you! Patrick Pagano B.S, M.F.A Assistant Professor in Residence Digital Media & Design Web & Interactive Technologies University of Connecticut, Stamford (352)-226-2016

2 3

Multiple instances of external - interference
by Joel Matthys 12 Jun '17

12 Jun '17

Hello everyone. I'm rewriting an external for the RTcmix audio language. I have built RTcmix as a static lib and compiled it into my external, accessing the functions from RTcmix through its API in the code for my external. I have it up and running, but if I create multiple instances of the external in the same patch, they interfere with one another, garbling the audio and corrupting the memory. Any ideas on fixing this? I had assumed that linking against a static library meant that there would be no shared namespace. Thanks! Joel

2 1

GEM question - glsl and shared context
by oliver 10 Jun '17

10 Jun '17

hi, dear list ! attached is an example patch that should demonstrate my question ... as far as i understood, once a texture is "made" (i.e. from a [pix_image]) it can be shared by other render chains by connecting its right outlet to another texture's right inlet (the whole list has to be provided) while this works in a simple setup, i tried the same with a glsl effect in between. this one didn't work as expected, as the shared texture was the original one (BEFORE the shading effect) how would i distribute the texture AFTER the shading program ? thanks in advance ! a more general question: finding tutorials or "manuals" about GEM (especially about openGL, textures and glsl stuff) is quite confusing and frustrating at times, so the learning curve for a noob like me is quite steep. simple setups as described in the example patches work alright, but once i try to adapt them to slightly different scenarios i usually end up completely blank. for example: what is the "texunit" message as opposed to the texture id ? anyway, i just wanted to ask the list if there are some sort of "tutorial" or "lessons" stuff concerning GEM ? so far i found these the most useful and elaborate: https://github.com/extendedview/extended_view_toolkit (best one !) https://github.com/b01xy/glsl http://grh.mur.at/blog/pd-workshop-joanneum but something a little more "basic" or "systematic" would be great ! still, GEM is enigmatic but great, i can only guess its complete powers, will keep hanging on ! best oliver

2 1

vline~ with switch~ off
by Matt Davey 09 Jun '17

09 Jun '17

is this still an issue? I have heaps of patches with vline~ in, and CPU seems to creep up from them getting messages when switch~ is off. I thought this got looked at? Actually....is there any way just to turn off all control messages in patches that have [switch~] turned off? I mean, how often do you want those going through when the signal objects aren't being processed?

5 6

Open Call: PIKSEL17 -- deadline July 1st!!
by 220hex 09 Jun '17

09 Jun '17

(sorry for x-posting) -- Piksel17 November 16-18 2017 Bergen, Norway - - Piksel is an international festival for electronic art and technological freedom. Part workshop, part festival, it is organized in Bergen, Norway, and involves participants from more than a dozen countries exchanging ideas, coding, presenting art and software projects, doing workshops, performances and discussions on the aesthetics and politics of free technologies. - - open CALL for PROJECTS For the exhibition and other parts of the program we currently seek projects in the following categories: 1. Installations Projects to be included in the exhibitions. The works must be realized by the use of free and open source technologies. For Piksel17 we specially encourage projects in the field of DIY BIOart and renewable/sustainable technologies to apply. 2. Audiovisual performance Live art realized by the use of free software and/or open/DIY hardware. 3. Presentations Innovative DIY/open hardware and audiovisual software tools or software art released under a free/open license. (Also includes presentations of artistic projects realized using free/open technologies.) For Piksel17 we specially encourage projects in the field of DIY BIOart and renewable/sustainable technologies to apply. 4. Workshops Hands on workshops utilizing free software and/or open/DIY hardware for artistic use. For Piksel17 we specially encourage projects in the field of DIY BIOart and renewable/sustainable technologies to apply. 5. PikselSavers Video and software art based on the screensaver format – short audiovisual (non)narratives made for endless looping. Possible thematic fields includes but are not limited to: sustainable resource allocation, renewable technologies, energy harvesting, fair trade hardware, free content, open access, open data, DIY economy, shared development. The works must be realized by the use of free/open source technologies. - - !!!!!!!!!! Deadline - july 1. 2017 !!!!!!!!!! Please use the online submit form at: http://piksel.no/ocs - - Piksel17 is supported by the Municipality of Bergen, Arts Council Norway, PNEK and others. more info: www.piksel.no

1 0

lsl_inlet~ now available
by David Medine 09 Jun '17

09 Jun '17

For those interested, I pushed onto my github page (https://github.com/dmedine/PdLSL/tree/master/lsl_inlet%7E) a Pd extern that wraps LabStreamingLayer's signal inlet. Now you can stream data into Pd with LSL. This is still fairly unpolished. It still crashes sometimes for reasons I don't understand, and the number of outlets you can have is limited to 1, 2, 4, 8, 16, or 32. I figured no one wants to draw 256 wires out of a single extern. As I say, it's a little crashy still, but I will battle test it it a little bit this weekend and maybe figure out the problem. Probably a threading issue. [lsl_outlet~] still to come.

3 3

wild structs on pd files
by João Pais 09 Jun '17

09 Jun '17

Hi again Miller, I had a question regarding structs. When editing my patches in a text editor, I noticed that at the top of the patch there were some "stowaway" structs (and scalars), which can only come from abstractions I used in the main patch - but these abstractions should have the structs inside them, and not on the main patch. Nevertheless, the main patch begins now with some #N struct .... lines, before the first #N canvas ... . I also noticed that if I delete the #N struct .... lines there won't be any (visible) problem with the patch. Do you know this behaviour? Is it normal, or is it an open issue that should be dealt with? E.g. like arrays, should scalars have a "don't save with patch" option? Furthermore, this brings up the subject of old data (i.e. trash) hanging around a patch that isn't visible to the "naked eye": - does this data in any way affects or conflicts with the patch? - does it get ignored, thrown away or rewritten at restart of the patch? Adding to that, I use $0-variables in my struct names, which will mean that in one session they will be called 1007-bla, and 1920-bla in the next one. - since the only way to know how many structs are saved within a patch is by looking at the patch code, and the only way to delete structs in Pd is graphically, would it make sense to add a struct-scanning and delete methods in [pointer], or a way to scan it by sending it a pd-canvas identifier? - or looking at it from another angle, since inside Pd the only way to be sure to clean a canvas is the send a "clear" method, would it help to implement a "clear-struct" method to a pd canvas? Or even "clear-struct all" that could be sent to the top canvas of a patch, and clean all subpatches recursively? Best, Joao

3 4

Re: [PD] variable outlets in dsp object
by Pierre Guillot 08 Jun '17

08 Jun '17

I don't fully understand what you do in your code without the rest of it. I think the simplest approach is to keep all the DSP information you need in your object's structure(number of samples, pointers to the inlets, pointers to the outlets, etc.) and to call the dsp routine with only your object structure as argument (and the perform method returns w+2). If you want an example, I made a vbap~ object that has variable number of inlets and outlets. Here the code: https://github.com/pierreguillot/vbap/blob/ master/pd/src/vbap_tilde.c Cheers, Pierre

2 1

Re: [PD] variable outlets in dsp object
by Pierre Guillot 08 Jun '17

08 Jun '17

Or even simpler this code: https://github.com/pierreguillot/pd.dummies/blob/master/src/leeloo_tilde.c 2017-06-08 12:36 GMT+02:00 Pierre Guillot <guillotpierre6(a)gmail.com>: > I don't fully understand what you do in your code without the rest of it. > I think the simplest approach is to keep all the DSP information you need > in your object's structure(number of samples, pointers to the inlets, > pointers to the outlets, etc.) and to call the dsp routine with only your > object structure as argument (and the perform method returns w+2). If you > want an example, I made a vbap~ object that has variable number of inlets > and outlets. > Here the code: https://github.com/pierreguillot/vbap/blob/master/pd/ > src/vbap_tilde.c > Cheers, > > Pierre >

1 0

variable outlets in dsp object
by David Medine 08 Jun '17

08 Jun '17

I am writing a DSP extern that can have a any number of outlets depending on the creation arguments (like [fexpr~], e.g.). In order to interact with the outlets in the XXX_tilde_perform loop, I made a member of my t_XXX_tilde data structure thus: t_sample **lcl_outs; Then, when I know how many outlets I need, I allocate the appropriate amount of memory. In theXXX_tilde_perform loop, I set the pointers to those handed by Pd's scheduling engine in the standard way: for(int i=0;i<x->nouts;i++) x->lcl_outs[i] = w[2+i]; I found that this would sporadically crash Pd when turning the DSP engine on and off and (sometimes) when connecting/disconnecting to one of the outlets. I think that I have solved this problem by copying my pointers at the head of the XXX_tilde_perform method to a local variable: t_sample **lcl_outs = x->lcl_outs; for(int i=0;i<x->nouts;i++) lcl_outs[i] = w[2+i]; Everything /appears/ to work now. I assume that somehow Pd's engine is rubbing my x->lcl_outs ptr off of the stack. Thus, by copying it to another ptr I avoid this problem because my OS still knows where the allocated memory is. That is to say, when Pd gets rid of whateverw[2] is, it then removes the ptr lcl_outs, not x->lcl_outs, which still has memory behind it. Am I reading this right? I am not at all confident that I have truly solved this problem. If anyone has any insight, I'd like to know too. Thanks! David

1 1

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 June 2017