[PD-dev] call for discussion double-precision file extension

Christof Ressi info at christofressi.com
Tue Mar 29 18:10:15 CEST 2022


One "con" I can imagine is that there are "cleaner" alternatives than 
name mangling.

For example, VST3 plugins use a bundle structure which also allows for 
"merged bundles": 
https://developer.steinberg.help/display/VST/Plug-in+Format+Structure.

Something similar *could* work for Pd externals:

foo-lib/

-- bar.pd/

---- windows-amd64-64/bar.dll

---- windows-amd64-32/bar.dll

---- linux-amd64-64/bar.dll

---- linux-amd64-32/bar.dll

etc.

In this case, the .pd extension would be used both for Pd abstractions 
and external binary bundles.

But it might be overkill...

Christof

On 29.03.2022 17:49, Roman Haefeli wrote:
> On Tue, 2022-03-29 at 17:29 +0200, Christof Ressi wrote:
>> +1
> +1
>
>> I think it's nicer to use a common extension and have the
>> platform/arch/floatsize specifier as a seperate component.
>
>>> I didn't especially like this back then, but in the meantime i've
>>> come to the conclusion that it's probably the best way forward.
> Why? I think it is much friendlier for the user to see in the filename
> what is in it. If binaries are distinguished by installing them to
> separated folders (but still share filename), people will try to move
> files around to make things work and thus getting into a mess really
> quickly. One shouldn't have to use 'file pdexternal.ext' to know what
> actually is in it.
>
> Having said that, I'm still curious to know what you thought are the
> cons back then.
> Roman
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev





More information about the Pd-dev mailing list