Pd-dev November 2018

pd-dev@lists.iem.at

15 participants
12 discussions

file search path proposal
by Dan Wilcox 08 Nov '18

08 Nov '18

In working with sample file paths for a project, I again run into the issue that [readsf~] expects relative paths to it's patch. This means I have to generate a full path if it's used within an abstraction. This works, but it currently requires an external, both in vanilla and my usage of libpd in PdParty. After the small work I did with [declare -path] search mechanism, I'm thinking of something similar for the core objects that read/write files such as [textfile], [soundfiler], [writesf~], etc: * absolute path: work as normal (current behavior) * relative path starting with ./ or ../: always relative to containing patch (current behavior) * relative path (without ./ or ../): relative to top-level parent, ie. parent patch using an abstraction (new behavior) This would mean the default behavior would change to what I believe is the *expected* behavior by most: sending a relative path to an object is relative to whatever main patch is using the object, whether it's in an abstraction (however many levels deep) or not. This also means projects which use these objects on their main level would work normally. The only thing that might break would be using one of these objects within an abstraction and *expecting* the path to be relative to the abstraction, not any parent. In this case, I introduce the explicit ./ or ../ check which forces the paths to be treated as relative to the abstraction. This also implicitly removes the *urgent* need for a suite of fuel path objects, at least for me. :) -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

4 3

Multiinstance support in libpd
by Thomas Mayer 07 Nov '18

07 Nov '18

Hi, I have taken up my work on my FLOSS projects again, and I am currently working on multiinstance support in libpd for the C# wrapper. The work is going quite well, only two things are bothering me: - I do not use the main instance (pd_maininstance in the Pd source code), because not using it makes the wrapper easier to maintain. What are possible negative side effects of that? - As far as I can see, MIDI and messaging hooks are not associated with a Pd instance, and especially not decoupled. Is there a way to set hooks to instances, and hook up to the same symbol in different instances? How would that be possible in libpd code? What are changes in Pd itself, if necessary? Thanks, Thomas -- "As long as people kept worrying that the machines were taking over, they wouldn't notice what was really happening. Which was that the programmers were taking over." (Robert Anton Wilson - The Homing Pidgeons) http://www.residuum.org/

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev November 2018