[PD] array size (was Re: arraysize)
Jonathan Wilkes
jancsika at yahoo.com
Thu Oct 4 15:57:57 CEST 2012
----- Original Message -----
> From: Ed Kelly <morph_2016 at yahoo.co.uk>
> To: Hans-Christoph Steiner <hans at at.or.at>; Miller Puckette <msp at ucsd.edu>
> Cc: "pd-list at iem.at" <pd-list at iem.at>
> Sent: Wednesday, October 3, 2012 11:56 PM
> Subject: Re: [PD] array size (was Re: arraysize)
>
> I think you can't fix a bug in a core object and retain complete backwards
> compatibility in terms of the audio result of old patches, unless you implement
> a "pre-0.44 mode" or something. But why would you want to do
> that? Perhaps a method can be used to switch between the two modes in hip~, but
> that might introduce a small overhead.
>
> I think the integrity of the objects in terms of what they should do is more
> important than total backwards compatibilty - old patches will still load, but
> they may not sound _exactly_ the same. Personally I'd like hip~ to do
> highpass filtering properly, and so my expectation when I invoke hip~ is that it
> will do exactly that. Having a patch that "works like this but I don't
> know why" is a bad thing. I'd be sure to find the tiny DC component a
> nuisance at some point.
Did you?
>
> Ed
>
>
>> For the hip~ problem, I'm fine with just fixing it in 0.44, leaving it
>> as hip~, and being done with it. I agree with Jonathan: the default
>> behavior should be the non-buggy behavior.
>>
>> The issue I am addressing is the -pre-0.44-hip idea and other ideas for
>> providing backwards compatibility. Namespaces provide a nice, clean
>> technique for doing this, on top of other advantages. And if we
>> implement them right, people will only need to know about them if then
>> need to do advanced things like running a patch in 0.44 while using a
>> 0.42 compatibility mode.
>>
>> Most users are just going to see the [import] or [declare] statement in
>> a patch. I think that's proven to be a much more newbie-friendly way to
>> load external libraries than command line flags, especially on Mac and
>> Windows.
>>
>> Namespaces are part of general programming, and are essential unless you
>> are willing to greatly limit the domain the language is used for. I
>> think we can implement namespaces that are simple and Pdish. I think
>> we're close. Even C requires the use of a crufty form of namespaces.
>> Try writing a C program without a single #include.
>>
>> .hc
>>
>> On 10/02/2012 08:33 PM, Miller Puckette wrote:
>>> Right, the two demands I'm trying to reconcile are keeping the name
>>> hip~ (so that old patches remain comprehensible) and yet making hip~
>>> work correctly -- it's a bug fix. Seems to me one ought to be able
> to fix
>>> bugs without diving into library version confusion.
>>>
>>> I think namespaces are very useful to expert programmers but are likely
> to
>>> be confusing to many Pd users -- and its not that much of a necessity
> if
>>> indeed c (in which Pd and linux are implemented) didn't need to
> have
>>> them.
>>>
>>> cheers
>>> Miller
>>>
>>> On Tue, Oct 02, 2012 at 08:24:19PM -0400, Hans-Christoph Steiner wrote:
>>>> If you think that's the preferrable approach, then
> shouldn't it be
>>>> [newhip~]? One thing libc did not do is break backwards
> compatibility
>>>> of functions. I think the libc example is a better approach than
> the
>>>> -pre-0.44-hip flag or the aliasing to work around the existing
> versions
>>>> of [pow].
>>>>
>>>> My central point is that Pd should have a fully functioning
> namespace
>>>> like modern languages do (C++, Obj-C, Java, Python, Ruby, Lua,
> Haskell,
>>>> etc. etc.) That's one lesson that we've learned from C.
> Part of that
>>>> is having a standard library that can be overridden. Then if
> people
>>>> want to have old versions of the standard library, they can easily
> be
>>>> accomodated by adding the version number to the name of the
> library.
>>>>
>>>> .hc
>>>>
>>>> On 10/02/2012 07:02 PM, Miller Puckette wrote:
>>>>> The libc way is just to have one libc and kludge your way
> through
>>>>> compatibility problems. For instance, seek() had to be
> replaced with lseek(),
>>>>> gets and fgets were left with not-quite-the-same behavior,
> errno was
>>>>> magically adapted to become a macro that grabbed a thread
> variable when
>>>>> threads appeared, etc. It's not pretty but way preferable
> to having
>>>>> several versions of libc - what a nightmare that would have
> been.
>>>>>
>>>>> cheers
>>>>> Miller
>>>>>
>>>>> On Tue, Oct 02, 2012 at 06:48:46PM -0400, Hans-Christoph
> Steiner wrote:
>>>>>> Is the static variable you are talking about the
> "static t_class"
>>>>>> declaration in the class C files?
>>>>>>
>>>>>> What's the libc way?
>>>>>>
>>>>>> The -pre-0.44-hip way would be easy to implement, but it
> has a number of
>>>>>> problems:
>>>>>>
>>>>>> - there will be many flags like this, -pre-0.42-pow, etc.
> etc.
>>>>>>
>>>>>> - there will be no way to specify in the patch that it
> should use a
>>>>>> specific version of hip~, pow~, etc. That adds complexity
> to the patch
>>>>>> setups since each patch will need an accompanying script
> for launching
>>>>>> Pd properly and means Pd programmers have to learn non-Pd
> things like
>>>>>> scripting to do this.
>>>>>>
>>>>>> .hc
>>>>>>
>>>>>> On 10/02/2012 06:39 PM, Miller Puckette wrote:
>>>>>>> Actually I think my previous post was wrong - what I
> was unable to do was
>>>>>>> get different sets of static variables for dlopen() -
> ing the _same file
>>>>>>> twice_ -- which isn't what we're talking about
> here.
>>>>>>>
>>>>>>> But still, I think the libc way is much simpler and
> likely to be much more
>>>>>>> robust.
>>>>>>>
>>>>>>> cheers
>>>>>>> M
>>>>>>>
>>>>>>> On Tue, Oct 02, 2012 at 06:13:32PM -0400,
> Hans-Christoph Steiner wrote:
>>>>>>>> Since Pd manually loads the libraries (.pd_linux),
> it can also manually
>>>>>>>> map a given function address to the s_thing in the
> symbol table. There
>>>>>>>> is no need to load the symbols in a .pd_linux in
> the sense of a public
>>>>>>>> shared library, and therefore no nameclashes. Pd
> could get the address
>>>>>>>> of the new() function using dlsym() and store that
> wherever. This is
>>>>>>>> already happening for the setup() function, so we
> can do the same thing
>>>>>>>> to map the new() function to a symbol..
>>>>>>>>
>>>>>>>> So for example, pd could map the new() function to
> the fully qualified
>>>>>>>> name in the symbol table, i.e
> "vanilla-0.42.5/hip~", then only in the
>>>>>>>> canvas_local namespace would the symbol
> "hip~" be mapped to the new()
>>>>>>>> function.
>>>>>>>>
>>>>>>>> .hc
>>>>>>>>
>>>>>>>> On 10/02/2012 05:09 PM, Miller Puckette wrote:
>>>>>>>>> I'm not sure that any of the Windows,
> MaacOS, and linux dynamic loading
>>>>>>>>> systems will support having multiple versions
> of a library loaded in the
>>>>>>>>> same address space. But here's a simpler
> way anyhow: libraries such as
>>>>>>>>> vanilla could maintain compatibility by
> querying the version number of
>>>>>>>>> the patch at run time.
>>>>>>>>>
>>>>>>>>> In the case of hip~ I'm genuinely not sure
> whether the "correct" behavior
>>>>>>>>> would then be to revert to the old behavior for
> all old patches or only on
>>>>>>>>> request. The confusing scenario I worry about
> is that you have a patch with
>>>>>>>>> an old hip~ object in it, save it from 0.44,
> and then have it switch to the
>>>>>>>>> new behavior next time it's loaded.
>>>>>>>>>
>>>>>>>>> I think I have found ad hoc ways to fix the
> other problems without breaking
>>>>>>>>> old patches.
>>>>>>>>>
>>>>>>>>> cheers
>>>>>>>>> Miller
>>>>>>>>>
>>>>>>>>> n Tue, Oct 02, 2012 at 11:36:47AM -0400,
> Hans-Christoph Steiner wrote:
>>>>>>>>>> I think having a compatibility version
> stamp in the patch is a good
>>>>>>>>>> idea. This ties in well with the
> experiments I've been doing with
>>>>>>>>>> splitting out all of the objects from pd
> itself. If all of the core
>>>>>>>>>> objects are a standard library, then that
> means its easy to choose which
>>>>>>>>>> version of the standard library that a
> patch is using. In Pd-extended,
>>>>>>>>>> this is called the 'vanilla' lib,
> and its been included in some form
>>>>>>>>>> since 0.42.
>>>>>>>>>>
>>>>>>>>>> Then if a patch has a compatibility version
> stamp in it, Pd can
>>>>>>>>>> automatically look to see if it has a copy
> of that version of the
>>>>>>>>>> standard library, and load it. Otherwise,
> it would load the version
>>>>>>>>>> closest to that, and throw a warning, or
> optionally that could be
>>>>>>>>>> considered an error.
>>>>>>>>>>
>>>>>>>>>> To make this work well, the key missing
> feature is the ability to change
>>>>>>>>>> which loaded library an object name maps to
> in the canvas-local
>>>>>>>>>> namespace. Currently, once an object name
> is mapped to a loaded
>>>>>>>>>> .pd_linux, that is a global association.
> This is needed so that patches
>>>>>>>>>> using different standard libs can be open
> at the same time.
>>>>>>>>>>
>>>>>>>>>> Then making the versioned standard libs
> would be pretty easy, mostly
>>>>>>>>>> just bundling the right .c files into a
> lib.
>>>>>>>>>>
>>>>>>>>>> .hc
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 10/02/2012 11:15 AM, Miller Puckette
> wrote:
>>>>>>>>>>> This is in my long-range plan but
> hasn't yet risen to the level of "urgent".
>>>>>>>>>>> However, this migth be a good moment to
> get started on this because several
>>>>>>>>>>> other backward- and even
> forward-imcompatible needs are also rising to the
>>>>>>>>>>> fore:
>>>>>>>>>>>
>>>>>>>>>>> 1. there's a bug in hip~ - its DC
> gain is slightly (and possibly considerably)
>>>>>>>>>>> greater than 1. "fixing"
> this will change the audio output of older patches,
>>>>>>>>>>> usually much too slightly to matter,
> but there will have to b a "-pre-0.44-hip"
>>>>>>>>>>> flag or something to allow strict back
> compatibility;
>>>>>>>>>>>
>>>>>>>>>>> 2. There's no place in the pre-0.43
> file format to alow specifying individual
>>>>>>>>>>> box widths and font sizes; I put an
> "f" (=format) message to the canvas
>>>>>>>>>>> object in 0.43 so that in 0.44 I can
> make it set font size and box width and
>>>>>>>>>>> perhaps leave an opening for other
> formatting info.
>>>>>>>>>>>
>>>>>>>>>>> 3. the upsampling inlet~ by default
> zero-pads its input. This is incorrect as
>>>>>>>>>>> its DC gain is less than one. (Try
> using that as input to a phasor~ for
>>>>>>>>>>> instance - bad surprise!) I want to
> change the default so that it acts like
>>>>>>>>>>> a sample-and-hold, which I believe is
> an option now. To preserve back
>>>>>>>>>>> compatibility I'd keep all the
> "upsampling methods" in place but only change
>>>>>>>>>>> default behavior for patches with a
> 0.44 or later version stamped on them.
>>>>>>>>>>>
>>>>>>>>>>> Each of these presents a different spin
> on the age-old issue of keeping
>>>>>>>>>>> total back compatibility in place, even
> when the compatibility is to preserve
>>>>>>>>>>> a big as in (1) and (3) - and arguably
> in the file searching too; I'm not sure
>>>>>>>>>>> whether to regard that as a bug or just
> over-hasty design.
>>>>>>>>>>>
>>>>>>>>>>> cheers
>>>>>>>>>>> Miller
>>>>>>>>>>>
>>>>>>>>>>>> Here's a good sketch of
> the idea
>>>>>>>>>>>>
> (http://puredata.info/dev/PdSearchPath):
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Proposed Functionality
>>>>>>>>>>>>
>>>>>>>>>>>> for path in paths do -- the core
> does this bit
>>>>>>>>>>>> for loader in loaders do
>>>>>>>>>>>> loader(path, library,
> object)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Existing Functionality
>>>>>>>>>>>>
>>>>>>>>>>>> for loader in loaders do
>>>>>>>>>>>> for path in paths do -- the
> loader does this bit
>>>>>>>>>>>> loader(path, library, object)
>>>>>>>>>>>>
>>>>>>>>>>>> .hc
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
> _______________________________________________
>>>>>>>>>>>> Pd-list at iem.at mailing list
>>>>>>>>>>>> UNSUBSCRIBE and account-management
> -> http://lists.puredata.info/listinfo/pd-list
>>>>>>>>>>
> _______________________________________________
>>>>>>>>>> Pd-list at iem.at mailing list
>>>>>>>>>> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>>
>>
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>>
>>
>>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
More information about the Pd-list
mailing list