Re: [PD-dev] trouble with Pd version strings

[IOhannes m zmölnig]

Am 12. Mai 2024 17:45:17 MESZ schrieb Christof Ressi :
>
>> the meaning of PD_VERSION_CODE is really "a single code(number) expression 
>> the (entire) version of Pd", and belongs into the same family as 
>> PD_VERSION_MAJOR ("a single (code)number expression the major version of 
>> Pd").
>> having PD_VERSION_MAJOR and PD_CODE_VERSION adds additional mental load that 
>> i would rather avoid.
>Agree 100%!
>

And thank god, Christof can parse my autocompletion English... 

Of course, it should have read: "a single code/number *expressing* the [...] 
version of Pd".


mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] ready to release 0.55 test version?

[IOhannes m zmölnig]

On 5/10/24 02:43, Alexandre Torres Porres wrote:

Em ter., 7 de mai. de 2024 às 14:59, Benjamin Wesch <
benjamin.we...@gmail.com> escreveu:


adding signal comparison/logical operators

https://github.com/pure-data/pure-data/pull/2054 seems like a very good
feature addition

+ 1 for these objects in vanilla

maybe i missed why including them could be controversial - but to me,
they seem like a natural part of the vanilla feature set and a
valuable addition.



There wasn't (at least up to now) any remark on why this could be
'controversial', and I can't see any 'controversy' either. Well, maybe th


as this has been dangling for a few days, i would like to comment.

- i don't think there is much controversy about the suggested feature.
- the proposed change is a *new feature*
- from a release perspective, it might already be too late to add new 
features for 0.55.0 (somebody mentioned "last minute changes"; which *i* 
would not be the place for new features).


i am of course not the release manager of Pd, and do not decide what 
gets in and what not.
i wrote this only to express that the non-inclusion of the desired 
feature might be simply a matter of unfortunate timing.


mdsr
IOhannes



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] trouble with Pd version strings

[IOhannes m zmölnig]

On 5/8/24 18:49, Miller Puckette wrote:
I couldn't immediately figure out how to fix the ugly Makefile.am stuff, 
and anyway the whole thing feels fragile to me.  What if we change 
PD_VERSION_CODE to PD_CODE_VERSION ?  Will that cause anyone trouble?




i see you renamed the define.
however, the recent changes accepted by you already fixed the parsing 
issues we were having, so the version in 1.introduction.txt was replaced 
correctly.


 all in all i do not see a reason to use 
PD_VERSION_{MAJOR,MINOR,BUGFIX} on one hand, and on the other 
PD_CODE_VERSION version.


the meaning of PD_VERSION_CODE is really "a single code(number) 
expression the (entire) version of Pd", and belongs into the same family 
as PD_VERSION_MAJOR ("a single (code)number expression the major version 
of Pd").
having PD_VERSION_MAJOR and PD_CODE_VERSION adds additional mental load 
that i would rather avoid.


I now see that the correct action from me (and dan) would have been to 
both object the rename and propose a fix.
rather than just propose a fix (and assume that this would obsolete the 
rename).

sorry for the inconvenience.

gfdmsar
IOhannes



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] trouble with Pd version strings

[IOhannes m zmölnig]

On 5/8/24 22:50, Dan Wilcox wrote:

PD_VERSION_CODE was added and shows up in the grep output as a second line. The 
fix is to simply filter it out when grabbing the values. A fix is here:

https://github.com/pure-data/pure-data/pull/2298


i missed your PR and submitted my own version for the fix, with a 
slightly different approach:
- use autotools $(VERSION) rather than doing the brittle calculations 
ourselves (this shifts the authoritative source for the version from 
m_pd.h to configure.ac; i think this is no great loss, as they must be 
in sync anyhow)

- also implement a fix for the non-autotools buildsystems (src/makefile.*)
- here i tightened the search filter to only include #defines of (e.g.) 
'PD_MAJOR_VERSION' itself, and not some arbitrary line that contains the 
"PD_MAJOR_VERSION" string (and filtering out known false-positives, like 
lines containing also "PD_VERSION_CODE")





gfmdsr
IOhannes


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] trouble with Pd version strings

[IOhannes m zmölnig]

Am 8. Mai 2024 21:29:43 MESZ schrieb Miller Puckette :
>No, it's a conflict between doc/Makefile.am and recent changes in m_pd.h.  
>doc/Makefile.am is quite fragile and a seemingly reasonablechange to m_pd.h 
>broke it.  I have to get to a couple of other things now but will try to 
>figure out what to do tomorrow... possibly just take the 
>version-number-setting hack out of the doc :)
>

I guess the simplest solution to the problem would be to use the version from 
configure.ac, and generate 'doc/1.manual/1.introduction.txt' from 
'doc/1.manual/1.introduction.txt.in' (just like the Makefile's are generated 
from Makefile.in).

Anyhow, I'll have a look at the sed-expression. Shouldn't be too hard


mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Any follow up on smspd, libsms (as in Spectral Modeling Synthesis) for realtime instrument ?

[IOhannes m zmölnig]

Am 9. April 2024 22:53:52 MESZ schrieb Winfried Ritsch :
>IOhannes, thanks for the fast fix.
>
>Now it works with the develop branch of pd (, if handled carefully), 

I only tested with my own local copy of smspd, which uses the original code 
(rather than the one available on deken), and it likes crashing a lot. 
One problem I see is that libsms is not at all threadsafe, but smspd uses 
threads...


mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Any follow up on smspd, libsms (as in Spectral Modeling Synthesis) for realtime instrument ?

[IOhannes m zmölnig]

Am 9. April 2024 11:28:36 MESZ schrieb Winfried Ritsch :
>Thanks for info, I forgot to mention.
>
>I worked with SMS-Tools, 10 years ago and  I saw already the deken package, 
>but  unfortunately it always crashed on my Linux Debian bookworm (libsms).

That would be 





mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Seeking co-maintainers for Scheme for Pd

[IOhannes m zmölnig]

On 3/17/24 06:14, Iain Duncan wrote:

It occurred to me thinking further that really one doesn't need to know
much about Scheme or Lisp, provided one is interested, as I didn't when I
started! The work is mostly in C. FWIW. :-)


how about moving the repository to  ?
there are always¹ some volunteers who can help with bugfixing and the 
like, and if someone is willing to dig deeper into scheme4pd, they can 
always join (and leave, if need be).


in general i think the pd-externals group is a good place for small 
team-maintained externals.



personally, i am interested in that external (and have plenty of C 
skills) - but honestly I have other things on my plate as well, so 
couldn't do a full time maintenance o fthe project.


gfmards
IOhannes

¹ for various degrees of "always"


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] How to free memory of t_symbol

[IOhannes m zmölnig]

Am 22. Februar 2024 10:19:27 MEZ schrieb Alexandros Drymonitis 
:
>I have a data structure with a symbol and an array of symbols that store array 
>names defined as:
>
>```
>t_symbol **x_weights_arrays;
>t_symbol *x_biases_array;
>```
>
>When I'm done with them, I want to free the memory, but calling 
>free(x_biases_array) doesn't seem to work, and once called, as soon as I try 
>to do something else in Pd (like unlock the patch and choose an object), Pd 
>crashes.
>

Never free symbols.
A symbol is created by `gensym` and owned by Pd.





mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] time for a quick bugfix update?

[IOhannes m zmölnig]

On 10/24/23 17:55, Roman Haefeli wrote:

On Tue, 2023-10-24 at 12:03 +0200, IOhannes m zmoelnig wrote:

On 10/24/23 10:52, Miller Puckette wrote:


before tagging, it would be cool if somebody could actually test the
macOS binary from
<
https://git.iem.at/pd/pure-data/-/jobs/57685/artifacts/raw/Pd-0.54-0-
66-g6e06cf65.dmg>


Tested on 12.6.3 (Monterey) / MacBook Pro 2019 (Intel i9):

   * GUI is responsive
   * Works with JACK
   * Input-meter flickering of mic input in testtone.pd makes Pd process
 jump to 66% in Activity Monitor.



hrmpf.


I have a 0.54 build with Tk 8.6.11 lying around on the same machine and
there the meter flickering only uses ~15% in Activity Monitor.

could you build Pd-0.54-1test1.1 on that machine with the olden Tcl/Tk 
and check whether this is a regression in Tcl or a regression within Pd?


gfmadsr
IOhannes


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] time for a quick bugfix update?

[IOhannes m zmölnig]

On 10/24/23 15:26, Miller Puckette wrote:
OK I think we're far enough along that I can tag and (once compiled) 
announce it...




fair enough.

while the CI is slow (as usual), the signed macOS binaries for 
Pd-0.54-1test1.1 are already available.


gfmadsr
IOhannes



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] OSX testers needed (was Re: time for a quick bugfix update?)

[IOhannes m zmölnig]

On 10/23/23 21:37, Dan Wilcox wrote:

There shouldn't need to be any patches applied. I double-checked and the last 
patch for 8.6.12 is integrated into 8.6.13 itself.

As for running an 8.6.13 Wish on earlier macOS versions... well that is an 
issue. The builds I had made all link to the UniformTypeIdentifiers framework 
which apparently was added to macOS 11 and later. Running this Wish on earlier 
versions seems to crash due to the load not finding the framework. What's 
interesting is that the Tk build system is supposed to weak link to it yet the 
loader still exits the app on start.

See the thread starting here: 
https://github.com/pure-data/pure-data/issues/2105#issuecomment-1774233455


yes (i think i linked to that thread in my original post).

anyhow, i think i might have fixed the problem.

The binaries found here

should be build with a Tcl/Tk-8.6.13 that runs on anything since 
OSX-10.9 Mavericks, either x86_64 and arm64.


i cannot test right now, so it would be great if people could do that 
while i sleep.

i'm esp interested in the extremes, that is:
- old macOS versions & old OSX versions (Mountain Lion anybody? but 
really any version that is no longer supported by Apple would be great)
- newest macOS versions (i can do some basic tests on Monterey tomorrow, 
but don't have access to Ventura or Sonoma machines)


the binary itself is not the latest and greatest 'master' branch, but a 
develop snapshot from earlier today (just so you know).


if all works well, i could switch the CI to the new Tcl/Tk tomorrow.

mgsdf
IOhannes


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] help coding an object, I need it cause I don't know better

[IOhannes m zmölnig]

Am 9. Oktober 2023 18:22:11 MESZ schrieb Alexandre Torres Porres 
:
>
>*var.c:80:22: **error: **assigning to 'float' from incompatible type
>'t_float *'*

Well it's just what it says: you are trying to assign a `t_float*` value to a 
`t_float`.
A `t_float` is some floating type, and it is not allowed to use it to store a 
pointer.

What's the question?



mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] external crashing when block size changes

[IOhannes m zmölnig]

Am 20. September 2023 09:07:18 MESZ schrieb Alexandros Drymonitis 
:
>Both of you were right. The 2 wasn't necessary, and indeed, I forgot to 
>multiply by the element type.
>




Actually I assumed that "2" was meant to be the element size, and thus plain 
wrong (it would be "4" on single precision and "8" on double).
So yes, use `sizeof(t_sample)`


mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] external crashing when block size changes

[IOhannes m zmölnig]

On 9/19/23 20:02, Alexandros Drymonitis wrote:

     x->bufbytes = x->chnls*2*sp[0]->s_n;


what is this "2" supposed to represent?

mfdsar
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] How to check data type of arguments in object

[IOhannes m zmölnig]

https://github.com/pure-data/externals-howto#class_new-1
https://github.com/pure-data/externals-howto#atoms

mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Closing old Github issues

[IOhannes m zmölnig]

Am 12. August 2023 04:40:01 MESZ schrieb Chris McCormick :
>
>I can recommend the following GitHub action for closing inactive issues which 
>is in place on a different project I contribute to:
>
>https://github.com/piku/piku/blob/master/.github/workflows/close-inactive-issues.yml


Personally I'm not very fond of autoclosing issues just because they went stale.

Eg I have a number of open bugs against gitlab-ce which I all find important 
(as a user), but have to ping them regularly to avoid auto-closing.


mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] switching app-id to info.puredata.pd?

[IOhannes m zmölnig]

hi,

i've played a little bit with getting Pd up on flatpak (yet another 
linux package manager), and currently the major showstopper is the 
app-id (:facepalm:)


the app-id is just a unique identifier for an application, that is based 
on some (reverese) domain scheme.
the app-id is used in a number of places, and for flatpak the app-id 
*must* match what we have in the "metainfo.xml" file.
our "metainfo.xml" file is "org.puredata.pd-gui.metainfo.xml" (found in 
the linux/ folder).

which means that the app-id is "org.puredata.pd-gui".

even though normally the app-id is not very visible to the user, i am 
sure that i DO NOT want the "pd-gui" part in there (for the full Pd 
application).


i have no idea what came over me when i picked this id when i added that 
file to the repository (because obviously it was yours sincerely who did 
that).


anyhow.
since i am about to change this id to some meaningful value, i wonder 
*which* would be a good one.


the obvious choice is "org.puredata.pd" (removing the "-gui" part).

now, i wouldn't write this email if i had no concerns about this 
name(and instead i would just change it).


my issue is that this id is depending on the ownership of "puredata.org".
now, "puredata.org" is gratefully sponsored to the Pd-community by A.van 
de Ven (at least it was, last time i was able to check; in the meantime 
you can no longer check who registered a domain...).

while i'm really thankful for this, it also has a few problems:
- avdv is not a really active member of the community (afaIk). in fact, 
it's rather hard to get in contact with them. the last record of a 
successfull contact between the two of us has been in...2007 or so.
 the last status i had was that avdv is willing to "perpetually 
sponsor" the domain, but eternity has become short in these days, and i 
don't know what will happen if anything ever happens to avdv (so let's 
hope for the best)
- "we" do not really control the nameservers. right now they are setup 
so that any requests for "puredata.org" or any subdomain thereof just 
points to the iem's IP address (that runs puredata.info). this kind of 
works, but only as long as we can serve everything from this IP.


i vaguely remember a problem due to this non-control of the nameservers 
with the libpd-for-android (or -ios?) packages a couple of years ago.



otoh, "puredata.info" is owned by the iem (my university).
while this is very practical for me ("master of the dns" and what not; 
my bus-factor is another problem in this context, but let's talk about 
that another time), the real benefit is that the university is not 
likely to go away within the next decades.

unis typically last longer than mere humans/mortals.

so my question is: could (and should) we switch the app-id from 
"org.puredata..." to "info.puredata...", just in case we ever need to 
*prove* that "we" actually own the domain.


there are of course caveats:
Pd uses the "org.puredata" namespace for storing settings:
- the GUI settings (on all platforms)
- on macOS it is used for storing the "normal" Pd-settings as well

so changing the namespace to "info.puredata" will discard all settings.



what do you think?

gamsdr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] how to have the same help file for different abstractions?

[IOhannes m zmölnig]

On 7/13/23 15:45, Alexandre Torres Porres wrote:

Hi, when compiling objects we can use "add creator" or "set help file" so
you can have the same help file for a group of objects or
creating aliased/abbreviated versions of an object. There's no way to do
this with abstractions though.

I also know there's no way to do something like this right now and that
we'd need some new object or external - maybe something in the realm of
iemguts, like a nem 'canvassethelp' object.


personally i think that the "set help file" functionality of the core 
should be deprecated, and instead force a one-object-to-one-helpfile 
mapping.

help-files could share a common abstraction to document similarities.

this is mainly driven by my desire to turn help-files into an easily 
machine-parseable description of an object. this could then be used for 
things like autocompletion, object browsers and deken search lists.


IIRC, the "set help file" functionality is really meant to assign 
help-files for objects that have names that are not easily representable 
on filesystems (e.g. using characters like '*', '/',...); also it was 
introduced in the dark ages when there was some confusion about the 
filename pattern for help files.



as for the "add creator": while i do not have a use-case for this right 
now, i agree that iemguts would be a good place for such an object:

> [objectalias bigfriendlyobject bfo].

there are practicaly caveats to this though.



gamrds
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] MIDI problems on linux

[IOhannes m zmölnig]

Am 21. Juni 2023 22:49:10 MESZ schrieb Miller Puckette 
:
>I'm having trouble getting "oss MIDI" (that is, access to /dev/midi*) working 
>in linux. Whereas in 0.53 I get choices "none", "/dev/midi3", "/dev/midi4", 
>"/dev/midi5", on 0.54 I get an extra entry, "(no device)".  When I select 
>"midi4" for example, the next time I open the dialog it shows "midi3".  I 
>think too that it' actually trying to open midi3, not midi4.
>


I take full responsibility, and it's on my to-do list (but it's also the end of 
the semester, so it might take a few days)


https://github.com/pure-data/pure-data/issues/2005


It just shows how much i hate MIDI


mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] double precision pd?

[IOhannes m zmölnig]

On 6/8/23 15:23, IOhannes m zmölnig wrote:

Oh no, compilation will be complex.


Not really.
You basically have to build twice...


oh no, i forgot about the intricacies of the windows build.

with macOS and Linux we have this nice single "pd" binary (or "pd64").
but with Windows we need the supporting pd.dll library where all the 
guts live (so externals have something to link against), and as of now, 
double-precision externals on Windows will link against pd.dll as well 
(but expect that to be contain the double-variant).


one possible solution for this is to put the double-precision pd.exe and 
pd.dll into PD/bin64/ or somesuch, although this is rather ugly in the 
general sense, requires us to duplicate some more files in both 
directories and would make the Windows installation diverge from the 
rest of the world even more (unless we are going to duplicate the 
ugliness on the other systems as well).


and there are probably some pitfalls along this way...

mgfdsar
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] double precision pd?

[IOhannes m zmölnig]

Am 8. Juni 2023 11:15:17 MESZ schrieb Lucas Cordiviola :
>How hard it would be to have both apps together in a single "Pure data" 
>package:
>

Interesting idea.

Esp for the windows packages (both the zip and the installer) I think that 
would make a lot of sense.

For the macOS app, I don't know whether it will work (but of course the 
downloadable dmg could provide both apps, and it might compress well enough 
that the additional content won't be a problem)

On Linux I prefer to split rather than merge, so I'm pretty sure I will package 
them separately on Debian


>$ pd
>
>$ pd64
>

But if course the two packages will be co-installable.
Depending on user demands, I might also consider pulling in the double-package 
via a "soft" dependency.


>Oh no, compilation will be complex.

Not really.
You basically have to build twice...

I don't think that the standard building workflow should be adjusted for the 
special case of building both variants (though now that I've written that, it's 
probably simple enough...)




mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] double precision pd?

[IOhannes m zmölnig]

On 6/4/23 17:22, Alexandre Torres Porres wrote:

well, great then, cause it's been merged :) time to get ready for double
precision finally then I guess! Really excited about it <3



the other question that ought to answered is: how do we actually call it 
in order to prevent confusion?


"Pd double precision" is a bit clumsy.

"Pd64" is terser ("pd64.exe", "libpd64.dll"; and that's what I called 
the tentative double-precision packages for Debian/Ubuntu/... for now) 
but of course there might be some confusion with amd64/x86_64/arm64...


gdsaf
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] double precision pd?

[IOhannes m zmölnig]

On 6/3/23 20:02, Alexandre Torres Porres wrote:

Hi, with pd 0.54-0 round the corner, what is still preventing us from
shipping double precision pd downloads?


from my side: https://github.com/pure-data/pure-data/pull/1605

it would be nice if this could be merged for the 0.54 release¹

in the meantime, i've instructed our CI to also produce a (signed) DMG 
for double-precision Pds.
i'll try to also generate Windows installers for sinlge/double precision 
(and 32bit/64bit pointers).


so it should be straightforward for miller to publish useable files 
fordouble precision.


but i really think that #1605 should be applied first.

fmdsa
IOhannes

PS: there's also some more of my PRs which i would like to draw special 
attention to (for inclusion with Pd-0.54)

- https://github.com/pure-data/pure-data/pull/1397
- https://github.com/pure-data/pure-data/pull/1590
others like #1929 or #1766 would of course be nice to have as well (as 
are most of my PRs ;-))


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] compiling externals for FreeRTOS

[IOhannes m zmölnig]

Am 20. Mai 2023 15:03:49 MESZ schrieb Alexandre Torres Porres 
:
>Em sáb., 20 de mai. de 2023 às 04:15, IOhannes m zmölnig 
>escreveu:
>
>> Running might be more complicated, depending on the demands of externals...
>>
>
>can you give me a potentially problematic example?

Exhausting memory...



mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] compiling externals for FreeRTOS

[IOhannes m zmölnig]

Am 19. Mai 2023 21:39:52 MESZ schrieb Alexandre Torres Porres 
:
>Hi, for a project with friends I'm gonna try and dig pd for freertos and
>esp32... so I wonder, how crazy would it be to compile externals for it,
>like quite simple ones coded in plain c, no great dependencies? thanks

Compiling: not very crazy, esp when using pd-lib-builder. Just get the 
toolchain and configure the compiler (CC, CXX,... variables)

Running might be more complicated, depending on the demands of externals...

And no: I haven't done this myself yet...



mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] problem loading tcl tk plugin with binary

[IOhannes m zmölnig]

On 5/15/23 06:15, Alexandre Torres Porres wrote:

Em dom., 14 de mai. de 2023 às 16:12, IOhannes m zmölnig 
escreveu:


presumably because there is no .popup created yet. if you experience this
"bizarre"


behaviour on exactly the same version of Pd across multiple systems


  just in one system and in one computer


not sur ewhat you mean here, but the nature of race-conditions is that 
they are hard to reproduce (across systems).
a race condition might happen on one system (reproducibly), and not show 
up on another system at all.




So, I'm not sure I get it but I'm assuming this won't be an issue in the
next version, right? Please confirm.


what would "not be an issue"?
with Pd-0.54 the ".popup" will not be created any more at all, so if 
your code depends on such an item, it will fail.
otoh, Pd-0.54 will replace the ".popup" with a window-specific 
"${win}.popup". this window-specific item will not be created until the 
window is created, so if your code depends on such an item to exist at 
startup time, it is likely to fail as well.




I can wait though, no problem. For now I'll just tell people to add else's
folder to the search path in preferences-->path and I can name the .tcl
file in order to load it as a tcl plugin like others.



ideally https://github.com/pure-data/pure-data/pull/1766 would be 
applied, in which case you just have to put an "else-plugin.tcl" into 
your "else" folder and it will be loaded automatically.


this will seamlessly integrate with your proposal (telling people to add 
the "else" folder to the path-preferences): it will just start to work 
automatically (for those who did not follow your instructions) whenever 
the PR is accepted.


in any case, please make sure that things keep working even if the 
GUI-plugin is not loaded (with degraded functionality obviously).



gmfsadr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] problem loading tcl tk plugin with binary

[IOhannes m zmölnig]

On 5/14/23 15:46, Alexandre Torres Porres wrote:

Em sáb., 13 de mai. de 2023 às 17:27, Alexandre Torres Porres <
por...@gmail.com> escreveu:


It seems the issue is a bit more bizarre and Pd just can't see this file
at startup somehow.



no, not that really. It seems the issue is simply what it says "*invalid
command name ".popup"*"

which doesn't really work at startup but works later or in my other
partition with another OS or my other machine with the same OS



presumably because there is no .popup created yet.
if you experience this "bizarre" behaviour on exactly the same version 
of Pd across multiple systems, then you are apparently running into some 
race condition.
(after all: there are two separate applications starting up: Pd-core and 
Pd-GUI. issuing a command in your external's setup-function will send 
out a Tcl-command *very* early in the process (at least if you are 
loading the external on startup), when the Pd-GUI might not be fully 
initialized yet)


note however, that up to Pd-0.53, Pd created a single global .popup menu 
(for the right-click context menu). as of Pd-0.54 (that is: current git 
'master'), this global .popup menu no longer exists (in order to fix 
[1303], and you obviously cannot use it.


gfmsa
IOhannes


[1303] https://github.com/pure-data/pure-data/issues/1303


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] problem loading tcl tk plugin with binary

[IOhannes m zmölnig]

Am 13. Mai 2023 17:50:09 MESZ schrieb Alexandre Torres Porres 
:
>but how can I use it? Simply trying to include 'load_plugin_script' gives
>me "symbol load_plugin_script not found"

It's a tcl-proc, not a C-function.
>From the C-side, call it via `pdgui_vmess`.


mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] problem loading tcl tk plugin with binary

[IOhannes m zmölnig]

Am 12. Mai 2023 21:51:15 MESZ schrieb Alexandre Torres Porres 
:
> within"category_menu::create .popup"("eval" body
>line 55)invoked from within"eval [read [open [file join
>/Users/ale/Documents/Pd/externals/else else-browser.tcl]]]"  


For starters, this is really not how you should try to load your gui-plugin.
Instead use the `load_plugin_script` proc. (Speaking of which: note to myself 
to remove the "tcl" extension when calling this proc)


mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Help with class_setsavefn

[IOhannes m zmölnig]

Am 27. April 2023 01:25:06 MESZ schrieb "Charles K. Neimog" 
:
>Hi,
>
>
> I have one problem with class_setsavefn, because I need something similar to 
> #X declare -lib mylibrary (an extra line in a specific place in the PureData 
> Patch file) to load the Python functions before pd tries to load the Python 
> objects that are added by the Python module (called pd).

[...]
>
>
>Question:
>
>  Someone already had to add some extra lines in the pd patch in some 
> specific order?
>
>  What is the right way to do it?
>
>
>One observation:
>  I am adding one new canvas_class method called py4pdLibrary, it loads 
>the Python Library (the objects).


That sounds all wrong.
I'm not exactly sure what you are trying to achieve, but most likely fiddling 
with the internals of the patch representation and adding methods to the canvas 
is not a good idea (for starters it will create very weird errors if your 
library cannot be loaded).

Here's what I would do
- check whether the relevant Phyton code has been loaded before instantiating 
the new object ( in the object's constructor (the C-wrapper part thereof)
- create a loader with `sys_register_loader`


mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Where is the universal wish for macOS?

[IOhannes m zmölnig]

Am 13. März 2023 16:59:30 MEZ schrieb Roman Haefeli :
>Hey all
>
>
>How are the official releases made? From where do they get their
>Wish.app?

https://git.iem.at/pd/pure-data/-/packages/

It's not in the git repository, because the one in the repo is used to build 
the legacy Pd-for-Mac



mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] new pd 0.53-2 stable release?

[IOhannes m zmölnig]

On 2/24/23 16:33, Alexandre Torres Porres wrote:

The changelog (a kind of release note) is clear about it


fine.
but would you, as an avid Pd-0.52-4 user (who currently cannot afford to 
upgrade) download cyclone-0.7.0 which was announced as "requires 
Pd-0.53-2" (so you kind of know that it won't work for you), then go and 
find the ChangeLog within the package just to see that indeed Pd-0.53-2 
is not required unless you open one of the help-patches and also notice 
that in some circumstances (which are best avoided in any case) one of 
the objects shows a wrong number?



how about instead adding a note to your help-patch that says:
> NOTE: On Pd<0.53-2 NaN-values are not displayed properly?

and then stop announcing the requirement on Pd>=0.53-2?


gmadsr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] new pd 0.53-2 stable release?

[IOhannes m zmölnig]

On 2/24/23 14:35, Alexandre Torres Porres wrote:

This is always "minimal". Cyclone has a [number~] abstraction that has been
in there for about 6 years. Thanks to 0.53 it can now print 'nan', this is
why 0.53 is required now.


so that's why you are "saying [that] it needs at
least 0.53-2"?

i'm sure there are people out there who think that not being able to 
print "nan" is a serious error, but i doubt there are many :-)




ELSE comes with a tutorial that is always up to date with latest Pd, so it


i was talking only about cyclone. no idea why ELSE came in (we can talk 
about ELSE once it stops breaking the interface between minor releases :-))


gmards
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] new pd 0.53-2 stable release?

[IOhannes m zmölnig]

Am 23. Februar 2023 18:14:23 MEZ schrieb Alexandre Torres Porres 
:
>Howdy, I just released Cyclone 0.7-0 and I'm saying it needs at
>least 0.53-2, which there's already a test version out. 

For an important library like "cyclone" I would welcome it, if it supported *at 
least* the last two stable releases (currently: 0.52.*, 0.53.*), and ideally 
something like the last 5 years.



mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] branch names (was Re: figuring out how to get everything merged)

[IOhannes m zmölnig]

On 2/6/23 23:07, Christof Ressi wrote:
Afterwards, maybe current development can be in the branch until 
ready, ie. feature/multi-channel or develop/0.54, etc? 

That's what I would suggest in general.

It would be great if all new features, rewrites, experiments, etc. could 
be made in feature branches. This has several advantages:


1. When working in a feature branch, you can mess around without 
worries. In the worst case, you can just roll back and force push. Also, 
it allows to squash the commits before merging for a nicer commit 
history (= less intermediate commits)


2. We can merge the develop branch into master any time and make bugfix 
releases while simulatanouesly working on new features.


3. The master branch would always be stable.



i think this sounds a bit like over-engineering in our case.
we almost have this scheme.

1. just name your branches "bugfix/clone-mc" and "feature/tasks".
2. we can already merge the "develop" branch into "master" any time
3. the "master" branch is mostly stable (untouched) anyhow.

btw, a "develop/0.54" sounds impractical, as it is not clear how that 
would be different from a "develop/0.55" branch.
(apart from the very simple (and trivial to solve) caveat, that 
currently `develop` is already a branch name, which occupies the entire 
'develop/' namespace)


afaict most branching strategies are not tailored towards the 
development model that Pd currently uses (a bdfl with short bursts of 
activity interrupted by longish breaks; a limited number of contributors 
who create their bugfix resp. feature branches).


there is probably room to improve the current development model, but the 
branching strategy should follow the development model rather than the 
other way around. (that is: if you want to change the development model, 
feel free to discuss it. but i think it would be better to do this first)


mgfdsr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Raise error from abstraction

[IOhannes m zmölnig]

Am 6. Februar 2023 21:24:54 MEZ schrieb Matt Barber :
>Hi dev list,
>
>Could there be a way to give abstractions the ability to raise pd_error()
>and highlight the abstraction instance with find last error? The reason for
>it would be that externals often distribute with a mix of binaries and
>abstractions, and it would be cool to have the user get an error pointer to
>the abstraction instance rather than the inside of an abstraction, e.g.
>when they send an unexpected data type.


I think my "log" library (available on denken, except for Darwin/arm iirc) 
provides something like this.


>
>Matt



mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] figuring out how to get everything merged

[IOhannes m zmölnig]

On 2/5/23 22:56, Christof Ressi wrote:
it's compiling just fine here using mingw so it's probably something 
stupid.

Are you building with ASIO support?


yes, that's crucial.
make sure you have ASIO extracted as asio/ASIO/

fdd
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] figuring out how to get everything merged

[IOhannes m zmölnig]

On 2/4/23 19:58, Miller Puckette via Pd-dev wrote:

I made a git branch off 0.53-1 and back-applied the portaudio update to it.


just a quick note: the current `master` seems to not build on 
Windows/MinGW any longer. seems to be related to ASIO.


see https://git.iem.at/pd/pure-data/-/jobs/46362

the '0.53-2' branch¹ however seems to build fine.
which is a bit weird...

on close inspection, it turns out that the portaudio/ directories in the 
'0.53-2' branch and the 'master' branch are indeed different.
i don't know why and how they have been imported (presumably with the 
'portaudio/update.sh' script, but the 
portaudio/portaudio/src/common/pa_gitrevision.h now shows 'unknown' 
which is not very helpful)




gfmdasd
IOhannes


¹ shouldn't that branch be called '0.53' instead, as it is (hopefully) 
will contain the entire 0.53-x history?


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] New object to detect # of channels? (was: Removing [output~]?)

[IOhannes m zmölnig]

Am 20. Jänner 2023 20:47:53 MEZ schrieb Alexandre Torres Porres 
:
>ok, here's a (maybe stupid) idea, currently, this object I designed gives
>you a channel number of "1" if nothing is connected to an inlet~, not sure
>if possible but maybe "sp[0]->s_nchans" could give us "0" if nothing is
>connected to an inlet~, so this object could be used to also detect inlet~
>connection...
>


Which inlet~?
I see that your use-case is centered around connecting this object directly to 
[inlet~], but in general this just will not be the case, so i think we should 
disentangle the two objects conceptually.
I don't think we have a precedent of a "companion object" that is only 
auxiliary to another go one.

Or put otherwise: do we want to an object that tells us how many connections 
the [osc~] object that connects to it has?

If this doesn't really work (and personally I'm not convinced that it does), 
merging the functionality into [inlet~] itself might make more sense...


mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] multichannel signals, preliminary support

[IOhannes m zmölnig]

On 1/17/23 20:55, Dan Wilcox wrote:

fan-in/fan-out? ('fi', 'fo')



I also thought of "fan in" and "fan out" ... probably to the consternation of IOhannes 
who added the "triggerize" feature. ;) 



not at all.
i hate message fan outs, but i think we are talking about signals here.

mgfd
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] multichannel signals, preliminary support

[IOhannes m zmölnig]

Am 17. Jänner 2023 17:21:38 MEZ schrieb Miller Puckette via Pd-dev 
:
>
>Incidentally, now I think the word "distribute" is ambiguous - does anyone

Incidentally I had a hard time figuring out what that "-d" flag was supposed to 
mean (without reading the sources), even though it is oh course mentioned in 
the comments.
I would have suggested something along the lines of "multichannel" (that is: 
'-m'), but Alex's fan-in/out makes sense as well...


mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [leapmotion] 2.3.1 linking failure on Windows

[IOhannes m zmölnig]

Am 3. Jänner 2023 23:10:59 MEZ schrieb William Brent :
>
>x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>src/leapmotion.o:leapmotion.cpp:(.text+0x411): undefined reference to
>`Leap::Frame::timestamp() const'

C++ is a fantastic language.
Unfortunately it is not really standardised on the binary level, which 
basically means that you might not be able to use c++ libraries compiled with 
one compiler/linker with binaries created by another compiler/linker.

Now, clang kind of guarantees binary compatibility with g++ binaries, which 
pretty much covers the Linux & macOS worlds.
Things are of course different on windows: you generally cannot mix MSVC 
libraries with GCC binaries (and vice versa), at least if c++ is involved.

Proprietary SDKs often provide MSVC libraries.

So if possible, try to use a C-library instead of a C++-library on windows.


mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Unconnected signals

[IOhannes m zmölnig]

On 12/14/22 12:48, David Rush wrote:

Maybe this is something I missed in documentation, but how is one meant to
tell if a signal inlet is connected or no


you don't.
why would you want to do that?
(as in: most likely you are breaking user expectation by trying to do 
something too clever)


amds
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Signing deken packages

[IOhannes m zmölnig]

Am 30. November 2022 00:35:47 MEZ schrieb Thomas Mayer :
>Hello,
>
>I have uploaded packages to deken, but have just found out, that these 
>packages were not signed correctly with my gpg key for reasons totally 
>unrelated to deken.
>
>Should I reupload the packages or should I sign these packages with gpg, get 
>the signature extension .gpg (or .asc or .sig), and should I upload those 
>signatures via the webinterface to 
>https://puredata.info/Members/residuum/software/purest_json/2.0.0/


deken uses detached signatures (.asc files), so you only need to (re)upload the 
signatures themselves (eg using the webinterface).







mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] release time?

[IOhannes m zmölnig]

On 11/27/22 18:57, Miller Puckette via Pd-dev wrote:

TO pd dev -

I'm fixing to make a bugfix release.  I just merged 'develop' and 
'Documentation'.
Anything else (fixes only, please, no new features) that I should look at?


i'm wondering about the major iemgui regression.
as of now, any external library that uses the g_all_guis.h 
infrastructure (e.g. the "iemgui" library, or moonlib's mknob) crashes 
with Pd-0.53.
antoine has updated moonlib to use the new infrastructure (but the 
binaries are now Pd-0.53 only). i started updating the "iemgui" library 
(but i haven't completed that yet).


so i wonder whether:
- we should keep binary compatibility with old binaries, probably at the 
cost of keeping two distinct iemgui-frameworks in the sources 
(g_all_guis-legacy and g_all_guis-new)
- we should retire the public iemgui API (just like we did for 
"error()"), so the only API for creating GUI externals is directly via 
the widgetbehaviour functions.


the two questions are somewhat orthogonal, but i think the question 
ought to be tackled.


as i've said before, my personal perference would be at retracting the 
API and not caring about ABI breakage, but that is a very radical 
approach, and rather unusual for the Pd world.


i am not very optimistic about being able to merge the new-style and 
legacy g_all_guis into a single ABI-compatible (with older binaries) 
interface. hence my radical approach.

but i can totally understang if such an approach is not acceptable.

i also do not have any numbers, on how many externals are actually 
affected by the current breakage (i only know of moonlib and iemgui; but 
there might be others)



gfmdsa
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] CI doesn't see 0.53-0test3 commit?

[IOhannes m zmölnig]

Hi all (but sorry, miller really) -

On 10/24/22 17:46, IOhannes m zmölnig wrote:
maybe things have changed a bit since i originally setup the mirroring 
and they could be simplified.


so i've re-evaluated the options for synching, and it seems i have found 
a solution that is now somewhat faster (whenever you push something to 
github, our CI is now notified directly¹ that it should sync again).


i also tried to push some tags directly to the 'master' branch on 
github, and they immediately showed up. either the issue miller was 
having has been resolved magically on the github side, or it is really 
something odd going on with miller's pushes.
if the problem still persists, there's also the option to create a tag 
directly via the webinterface which you (miller) could use instead of 
the temporary branch dance.



gmdsar
IOhannes



¹ well "more directly" at least. our git-server recieves a notification 
that it should sync, then a CI job is run that syncs the repositories 
which in turn triggers another CI run that re-builds whatever needs 
rebuilding)


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] CI doesn't see 0.53-0test3 commit?

[IOhannes m zmölnig]

On 10/24/22 17:15, Miller Puckette via Pd-dev wrote:

Hi all (but sorry, Iohannes really) -


i'm not entirely surewhat you mean by this.
i do get your emails via the mailinglist.



I'm back i nteh state where I can't push to github (I'm merging stuff
on my own machine and "git push origin --tags" says it's synced but github
still doesn't see the new commits I've made, or the tags.  So now I'm making
a new branch "pure-data/temporary-merge", pushing that successfully, then
whacking buttins on the github site to merge it into master.  This is stupid
and I'd like to find the underlying problem but I'm stumped at the moment.


that's indeed weird.
it might be totally unrelated, but i have seen outages of the github 
webinterface in the past weeks.

so maybe the simple solution is just to wait a bit longer?

also, i think a better monitor of the repo is to just do a local clone 
besides your "work repository", and see what you get back (that is: 
whether all the tags and commits you expect are there)






Meanwhile, though, I've managed now to get github to see my "0.53-0test3"
commit, and its tag, but now it doesn't show up on the CI system at
  https://git.iem.at/pd/pure-data/-/pipelines.

... I think this might be related to the first problem and the way I'm
trying to work around it, but I could be wrong about that.


git.iem.at takes a while to sync to github.
it basically works like this:
- you push to https://github.com/pure-data/pure-data/
- gitlab.com regularly *polls* the github repository for new changes
- if there any new changes it pulls them into
 
- it then pushes these changes to https://git.iem.at/pd/pure-data
- this triggers the CI on git.iem.at

this was the easiest system to setup, as github does not allow for push 
mirroring¹ (you *can* do that with a github-"action" (aka CI job), but 
it's much more complicated to do it manually and requires changes to the 
repository itself (which i don't really like) and needs to be guarded 
against forks), and the free community edition of gitlab (that is 
powering git.iem.at) does not allow for pull mirroring².



maybe things have changed a bit since i originally setup the mirroring 
and they could be simplified.


gfmdsar
IOhannes



¹ push mirroring: whenever the repository receives changes, they are 
automatically pushed to another repository
² pull mirroring: a repository watches another repository for changes 
and pulls them.


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] oops, wierd filename in "po" subdir?

[IOhannes m zmölnig]

Am 22. Oktober 2022 19:02:17 MESZ schrieb Miller Puckette via Pd-dev 
:
>HI all (but Iohannes I think, sorry) -
>
>CI build failed on a file "zho_h...@tw.po" in pd/po . this looks like it's a
>real language file but not named correctly?

Hmpf sorry. It worked on my local builds, although I somewhat anticipated 
problems.

I think it would be best to just remove it from Makefile.am for now.
Do you need a pull request for this? (I'm currently slightly knocked out)


mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] release pd 0.52 update?

[IOhannes m zmölnig]

On 10/21/22 22:18, Miller Puckette via Pd-dev wrote:

(In reply to Iohannes - I can't reply directly to the mail for some reason) -

I'm leaving for a 5-day trip Thursday - hoping to grind the
release out Monday so I have time to fix whatever turns out to be broken



thanks.

i've updated the i18n branch to include some more (and more complete) 
translations and also to actually build these translations (so they are 
shipped with the release binaries).


gfmds
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] release pd 0.52 update?

[IOhannes m zmölnig]

On 10/16/22 16:58, Miller Puckette via Pd-dev wrote:

OK, I'm convinced.  Anyhow there are plenty of possible version numbers left :)



:-)

i see you have merged another round of PRs.

do you have an estimate on when the release is going to happen?
i'm mainly asking because of the translations, which currently have 
gained a bit of momentum (dutch, french, german, korean, brazilean 
portuguese and russion are now complete; spanish almost; canadian 
english, italian and hungarian have also considerable portions translated).

i thought about pushing the ukrainian translation a bit.


in any case, it would be great to have an approx schedule, so i can 
prepare an updated i18n branch in time.



mgfyfx
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] release pd 0.52 update?

[IOhannes m zmölnig]

Am 14. Oktober 2022 18:13:00 MESZ schrieb Alexandre Torres Porres 
:

Em sex., 14 de out. de 2022 às 12:12, IOhannes m zmölnig 
escreveu:


Am 14. Oktober 2022 15:32:42 MESZ schrieb Antoine Rousseau <
anto...@metalu.net>:
>has been made obsolete by the
>recent rework of the interface to GUI

Speaking of which: I think a bugfix release 0.52.3 should probably *not*
contain the "rework of the interface to GUI", which is a rather big
change...



Why not? We're talking about things that had already been merged before,


So what?

i'm not really sure i understand what you mean exactly with "have been 
merged before".

the fact that the PRs have already been merged into master?
how is that related to "bugfix release"?



right? It seems to me most changes are "under the hood" and not proper new
features.



And all of them include regressions.


imho, a "bugfix release" is a promise to the user that says "nothing has 
changed with respect to the previous release, except we fixed these 
annoying bugs".

so i worry not about "features" but about "anything not a bugfix".

and with 0.52-3, plenty of things have changed (and a few annoying bugs 
have been fixed as well).
~70 C-files have been modified, and 3 header files have been modified 
(suggesting additions to the API)


so i just fail to understand why we can't just call it "0.53-0", as this 
clearly is beyond a "bugfix" release.



i'm probably highly influenced by semantic versioning [1], which is 
targetting versioning for libraries (API/ABI compatibility) rather than 
applications, but i think the model is so great that it can be applied 
to any software (that is not released very frequently).


in any case: i'm not the one who is deciding on the versioning.


gfmdsa
IOhannes


[1] https://semver.org/


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] release pd 0.52 update?

[IOhannes m zmölnig]

Am 14. Oktober 2022 17:12:02 MESZ schrieb "IOhannes m zmölnig" 
:
>
>Speaking of which: I think a bugfix release 0.52.3 should probably *not* 
>contain the "rework of the interface to GUI", which is a rather big change...


Also I see that my deken update branch has been merged, which is great. But it 
includes mostly new features, rather than just bugfixes.

So are we aiming at 0.53.0 or at 0.52.3?


mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] release pd 0.52 update?

[IOhannes m zmölnig]

Am 14. Oktober 2022 15:32:42 MESZ schrieb Antoine Rousseau :
>has been made obsolete by the
>recent rework of the interface to GUI 

Speaking of which: I think a bugfix release 0.52.3 should probably *not* 
contain the "rework of the interface to GUI", which is a rather big change...


mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] tilde object rework ideas

[IOhannes m zmölnig]

(re-sending to the list)

Am 2. September 2022 20:12:54 MESZ schrieb Miller Puckette via Pd-dev 
:

Yep, s_nframes is best.

To Iohannes's point (s_n, s_nframes, and s_channels are redundant) , s_n needs
to be kept in the struct, and

then we could either have s_nframes, or s_nchannels,

in which case you'd get the other one by dividing.?? I have a deep horror of
integer division


Fair enough.

Note, that Christof's suggestion of s_n being the number of samples per 
channel (that is: it's what I suggested as s_nframes) does not require 
any division: we know the sample frames (s_n) and the number of channels 
(s_nchannels) and getting the total number of samples is a simple 
multiplication.


Given the issues pointed by Christof, this is probably the simplest 
solution.





Meanwhile, I'm going to propose that we not bother (yet) with automatically
vectorizing stuff like filters,



But of course, in order for christof's suggestion to work, the data 
ought to be "planar" (samples for the 2nd channel come after all the 
samples  for the 1st channel.


But for SIMD to be fun, data should be interleaved...


mfg.sfg.jfd
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Can't upload package with deken

[IOhannes m zmölnig]

On 6/29/22 21:11, Alexandros wrote:
Following up my own thread... the whole traceback reports that line 5 of 
~/.deken/virtualenv/bin/hy triggers the error, which is this:


from hy.cmdline import hy_main

The thing is that when I launch Python in the terminal and I type this 
line, it works fine. Both commands "python" and "python3" launch Python 
3.9.7. All python* symbolic links in ~/.deken/virtualenv/bin point to 
/usr/bin/python3 which is Python 3.9.7. This is as far as I can go, I 
think.



well, the virtualenv in ~/.deken/ probably ignores any system-installed hy.
at least, it used to (it now tries to use system-installed packages if 
they meet the requirements (e.g. are recent enough)...


first thing to try is simply to self-update deken:
```
deken update --self
```

if that fails, try uninstalled 'deken' first, before re-installing it (i 
havea gut feeling that there are some left-overs in your ~/.deken/ that 
make all the problems):


```
deken uninstall --self

xdg-open 
"https://github.com/pure-data/deken/blob/main/developer/README.md#manual-bootstrap;

```

gmfds
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] how to compile externals for apple silicon?

[IOhannes m zmölnig]

On 5/1/22 09:42, Dan Wilcox wrote

You cannot build for i386. Support for that arch was famously removed in macOS 
10.15 and those versions of Xcode which use its SDK, probably version 10 or so. 
Modern fat libs arm64 and x86_64.


just to add a bit of confusion...

technically, i think there's no difference between a "modern" and a 
"legacy" fat lib: it's a file format that can contain multiple 
architectures.
there's absolutely nothing keeping you from having a fat binary that 
contains arm64, x86_64, i386 and ppc.


the only obstacle is, that there is no compiler that can create binaries 
for all of these architectures.
but you can create the binaries on multiple systems (different macOS/OSX 
versions; different Xcode installations) and then use 'lipo' to merge 
the different single-arch binaries into a single fat one.


gmdsa
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Externals in Pd.52.2(Rosetta Mode) on Mac M1!

[IOhannes m zmölnig]

Am 30. April 2022 20:33:48 MESZ schrieb Roman Haefeli :
>
>tl;dr: Pd and Deken seem to do everything correctly on M1 Macs. 
>

thanks a lot for checking so thoroughly 


mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluidsynth~ (was: building fluid~ on Linux)

[IOhannes m zmölnig]

Am 30. April 2022 21:46:57 MESZ schrieb Alexandre Torres Porres 
:
> There are scripts taken from https://git.iem.at/pd/iem-ci to
>copy the libs to the same folder as the external. 

Please note that my localdeps.macos.sh does not deal with "universal" 
dependencies.

That is: if your dependency is already "fat", it will use it just fine.
But if your dependency library is only "thin" (eg x86_64 only), then the script 
will not magically embed a fat binary for you.

It seems it's pretty easy to build fat binaries even if your dependencies are 
only thin.
Esp. homebrew does not support building fat libraries, so if you used brew to 
install your dependencies you might miss some parts for a truly  universal 
package.
Sorry for the empty last email...

mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluidsynth~ (was: building fluid~ on Linux)

[IOhannes m zmölnig]

Am 30. April 2022 21:46:57 MESZ schrieb Alexandre Torres Porres 
:
>Hi, after more than a year, I'm finally going to release my fluidsynth~
>object as part of ELSE. There were lots of discussion on this list about
>this. One big issue was how to ship the external along with the library
>dependencies. There are scripts taken from https://git.iem.at/pd/iem-ci to
>copy the libs to the same folder as the external. It seems we got to a
>point of being able to build it for mac and windows. This last thread (from
>where I'm now opening a new one) was about building it for Linux.
>
>After so long I just tried to build it on my new system and my new
>challenge would be to see if it'd work for apple silicon macs. First I just
>tried building for mac intel using my new setup, a monterey machine with
>the latest XCode. I started by installing fluidsynth, now at a much more
>recent version 2.2.7, I then built the external and it worked fine in the
>system I built this on. I tried the localdeps.macos.sh script and it did
>copy all the libs to the same folder as the external, so I zipped it and
>uploaded to https://github.com/porres/pd-fluidsynth/releases/tag/0.0.0-test so
>I could test on another machine without fluidsynth and all... guess what?
>it didn't work!
>
>By the way, someone built it for windows and I was able to test that it
>works on a virtual windows machine, so I don't know what could be wrong
>with my setup... See
>https://github.com/charlesneimog/pd-fluidsynth/releases/tag/v0.0.1 note
>that there's also a mac version there, but it doesn't work either and seems
>to be worse than my attempt as there a no libs copied. You cal also test
>the linux version in there.
>
>Hope someone can give me a hint why my new attempt didn't work for mac, I
>don't know what could be different other than having a new system a new
>version of the OS, of XCode and fluidsynth.
>
>cheers
>
>
>Em qui., 14 de jan. de 2021 às 18:16, Roman Haefeli 
>escreveu:
>
>> On Thu, 2021-01-14 at 16:52 +0100, IOhannes m zmölnig wrote:
>> > On 1/14/21 10:42 AM, Roman Haefeli wrote:
>> > > See PR:
>> > > https://github.com/porres/pd-fluidsynth/pull/5
>> > >
>> >
>> > given that i consider myself upstream of the original
>> > "localdeps.*.sh"
>> > scripts and those scripts are located under
>> > https://git.iem.at/pd/iem-ci
>> > where they are used by a number of (our, that is: the iem's)
>> > libraries,
>> > i would highly welcome it if you could submit a PR to that central
>> > location rather than a single one of the consumers of those scripts.
>>
>> Sure. I wasn't even aware of the origin of those files.
>>
>> Re PR/MR:
>> While logged in as reduzent, I see only comport listed as repos I can
>> create MRs for. I don't seem to have privileges for forking on
>> git.iem.at nor for creating MRs for the iem-ci repo. Tell me if I'm
>> overseeing something.
>>
>> I created a fork on:
>> https://gitlab.zhdk.ch/rhaefeli/iem-ci
>>
>> You'll find the script addition in the linuxdep branch.
>>
>> Roman
>> ___
>> Pd-dev mailing list
>> Pd-dev@lists.iem.at
>> https://lists.puredata.info/listinfo/pd-dev
>>



mfg.sfg.jfd
IOhannes___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] error missing in Pd 0.52

[IOhannes m zmölnig]

Am 30. April 2022 14:41:49 MESZ schrieb Roman Haefeli :
>In some cases, it's not feasible to provide the pointer to the object,
>for instance in helper functions that don't have it specified as
>argument. How many levels deep do you think it makes sense to extend
>the function calls by x? 
>

42.


mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] error missing in Pd 0.52

[IOhannes m zmölnig]

Am 29. April 2022 16:27:04 MESZ schrieb Roman Haefeli :
> "pd_error(0, ...)" should be
>> equivalent and not break the external in old versions of Pd.
>
>So, if the pointer to the object (x) is not available, I can simply set
>it to 0 (or NULL)? 

Yes.
But please do take the opportunity and provide a valid pointer-to-the-object 
whenever possible, as this allows the user to track down,the source of the 
error.


> Forgive my noobish question, but Pd doesn't crash
>when I call that function this way?

No, it doesn't crash.


mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Externals in Pd.52.2(Rosetta Mode) on Mac M1!

[IOhannes m zmölnig]

Am 27. April 2022 19:34:01 MESZ schrieb Jakob Skouborg 
:
>
>Iemlib:- Seems like objects does not work. Like init, filter~, 
>vcf_filter~, aspeedlim, etc. neither with or without

You have to both *load* iemlib, and add it's *path*.

Typically you would add this to your patches depending on this library:
[declare -path iemlib -lib iemlib]


mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Externals in Pd.52.2(Rosetta Mode) on Mac M1!

[IOhannes m zmölnig]

On 4/27/22 14:15, Christof Ressi wrote:
When you start Pd through Rosetta (by right-clicking the app-icon and 
selectign "Open using Rosetta"), you instruct the OS to launch the 
Pd-GUI through rosetta.
The Pd-GUI then starts the Pd-core, and doesn't care a bit about your 
rosetta-settings, which means that the Pd-core is started in native 
(arm64) mode. 
Are you sure? I thought that when a universal binary is executed as a 
child process, it will "inherit" the architecture of the parent process 
by default.


no, i'm not sure.

it's what i concluded from jakob's problem description.

denis' answer proves that you might be right.

fdmsa
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] how to compile externals for apple silicon?

[IOhannes m zmölnig]

On 3/10/22 23:57, Dan Wilcox wrote:

I have a fork of pd-lib-builder which supports arm64 & universal builds on 
macOS. The PR has been sitting for some time but we have been using it successfully 
for a few projects for some time now:



note that the merit of the PR is mainly in autodetecting which 
architectures the current compiler might support.


if you know that your compiler supports both amd64 (aka M1) and x86_64 
(aka intel), you can simply call make with your target architectures, 
using the normal pd-lib-builder.


e.g. for building universal binaries, use:

```
make arch="arm64 x86_64"
```



mgfdsf
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] getting rid of warning (incompatible integer to pointer conversion )

[IOhannes m zmölnig]

Am 23. Februar 2022 15:39:03 MEZ schrieb Christof Ressi 
:
>
>Don't just try to get rid of warnings by doing random things until they 
>go away. Instead, try to understand them


+0.1


mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pointer cast fix

[IOhannes m zmölnig]

Am 21. Jänner 2022 20:31:57 MEZ schrieb Dan Wilcox :
>
>Would it be safe to do a cast to (unsigned long)?
>
>sprintf(buf, ".x%lx", (unsigned long)x);

no, because on LLP64 systems, an 'unsigned long' is only 32bit.

there relevant GitHub issue is 



mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Why not use portaudio per default?

[IOhannes m zmölnig]

On 1/21/22 14:59, Christof Ressi wrote:


What about my proposition to include portaudio as a submodule


in general i do not like git submodules.

first of all they make problems when using 'git archive' to generate a 
source tarball (e.g. when you create a 'git tag', GitHub offers you a 
"Source Code" download which is created with this method).
this is often a problem for downstream packagers (e.g. for the Debian 
packages) where crucial parts are missing from the source tarballs.
in the specific case of portaudio i donÄt really mind, as in Debian we 
are using the system-provided PortAudio (and explicitely do *not* use 
the vendored version).


2nd, submodules do not allow for patching the vendored sources (e.g. we 
*could* remove the annoying printout at Pa_Initialize() in our vendored 
copy, but not with 'git submodule').
otoh, we haven't really used this in the past, so we probably don't need 
this anyhow.



so i really do not care.
what i do care about is that the portaudio backend implementation of Pd 
remains (API-)compatible with released stable versions of PortAudio (and 
ideally (API-)compatible with the version of portaudio shipped in major 
linux distributions, esp. Debian)




> now that it's officially on GitHub?

this i don't really understand. what makes GitHub different from 
BitBucket, GitLab, SourceForge or git.jackaudio.org with respect to 'git 
submodule's?



fgmdsa
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Why not use portaudio per default?

[IOhannes m zmölnig]

On 1/21/22 14:59, Christof Ressi wrote:
I'm not sure about ALSA. Here would should really compare and see if 
there's a real showstopper in the portaudio implementation (that cannot 
be easily patched).


my understanding is that the native ALSA implementation allows for the 
lowest latencies (at least under Linux)


but: i really don't know how well portaudio behaves in this respect.

What about OSS? I understand that it's legacy, so maybe we can just use 
the portaudio implementation?


i think the merit of OSS is that it allows to build Pd with *zero* 
external dependencies and still have sound (and MIDI): no libalsa, no 
libjack.


this is probably also the most compelling reason for MMIO.


mgfds
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Why not use portaudio per default?

[IOhannes m zmölnig]

On 1/21/22 14:59, Christof Ressi wrote:



i never use portaudio, as it never really *worked* for me.


 From what I read below, what you actually mean is: "I never use 
portaudio's Jack implementation because it is too limited for my use 
cases". I can't believe that portaudio never worked for you in general...


i remember having problems (as in: dropouts).
but this was years ago and because i had a running alternative 
(actually: two alternatives - JACK and ALSA) and so i had no incentive 
to spend time in improving my PortAudio experience.




portaudio already has a Jack-specific API to set the client name: 
https://github.com/PortAudio/portaudio/blob/master/include/pa_jack.h




probably.
my reference application is still audacity which on my system does not 
set the JACK name (but then: i'm using audacity-2.4.2 which i understand 
is not the latest and greatest)


- when using JACK via PortAudio, i can pick a destination where i want 
but how do i do any non-trivial routing: e.g. [adc~ 1 2] go to my 
soundcard channels 17 & 18 (the headphones), while [adc~ 3 4] go to 
JackTrip and all four channels go to Ardour?


Is this possible with Pd's implementation? How do you do this?


i'm using a dedicated JACK patching software (qjackctl).
the point is that Pd's JACK implementation does not interfere with my 
patching software.


That's also an issue with some ASIO drivers. At least with ALSA we 
should check


1) does this still happen with the latest portaudio version?

2) does portaudio offer a way to disable this?

3) can we add a way to disable this?

Another solution would be to temporarily disable console output (unless 
"sys_verbose" is set). In fact, this could also be nice on Windows.



i think the proper way would be to have a flag to Pa_Initialize() to 
suppress such output (or even better: a callback)

but that's of course something that needs to be changed in portaudio...



- finally when Pd *initializes* PortAudio i get one or more very nasty 
and loud click sounds (about 0dBFS). presumably this is because of 
some samplerate switching (but i really don't know).


I never had this problem...

1) Is this really a problem with portaudio itself, i.e. does it happen 
with several apps that use portaudio?


as i said: i see all the problems i described also on audacity.
this includes the click at initialisation.




2) If yes, does it still happen with the latest version?


dunno.



3) Does it only happen with certain backends?


it happens at initialization time.
e.g. when i start "audacity".
there are no problems when i turn on DSP (or in audacity: when i start 
playback)





fdcdsa
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Find external and install it in an custom folder does not work anymore in Pd 052.1on Debian ...

[IOhannes m zmölnig]

Am 6. Jänner 2022 18:58:47 MEZ schrieb Miller Puckette via Pd-dev 
:

>Here's a modest idea for an improvement - perhaps when Pd is started from 
>itself, not
>from the GUI, it should regard a missing docspath as meaning not to ask, but 
>when it's
>started form the TCL/TK layer we'd stick with the current behavior.
>

+1


mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] [PD-announce] Pd version 0.52-0test3 released

[IOhannes m zmölnig]

Am 12. Dezember 2021 21:05:14 MEZ schrieb Miller Puckette via Pd-list 
:
>
>
>Nope - Wish 8.6.12 seems to depend on newer Mac features than are
>on OSX 10.7.  
>
>But I'm OK with continuing to compile for 10.7 on my old machine and
>make it available to people like me :)
>

So how do we proceed from here?
Currently my CI builds are unable to create a working Wish.app themselves, so 
they fetch the universal builds from miller's site.
I don't really like this much, as I think the upload was mainly done for 
testing whether it works at all, rather than for deployment.

So: should these binaries be included in mac/stuff/? 

Or not (which i'm fine with as well, see my post scriptum. In any case I'd like 
to know)

(taking this to PD-dev)

mfg.sfg.jfd
IOhannes

PS: I can't believe I'm writing this - as I'm typically in the forefront of 
opposing any binary assets in git repositories.
probably I should just upload the packages to some CI related "asset store".


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Question about right hand generic inlet creation

[IOhannes m zmölnig]

Am 8. Dezember 2021 03:52:00 MEZ schrieb Iain Duncan 
:
>And follow up, if there is a way to make a generic handler for right hand
>inlets, is there also a way to find out on which inlet the message came in?
>


You basically need to create a "proxy" object with a single generic inlet.
The proxy object is not displayed (but its inlet is attached to and displayed 
on) the parent object.
It also holds a handle to the parent (so it can forward whatever it receives) 
and probably it's own ID (so it can identify itself)

just grep for 'proxy's 


mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] current master does not build on macOS Catalina

[IOhannes m zmölnig]

Am 1. Oktober 2021 12:31:16 MESZ schrieb Roman Haefeli :
>Hi
>
>I having troubles building current Pd on macOS catalina. This is how I
>run configure:
>
>  ./configure --enable-jack --disable-jack-framework --disable-locales
>
>And here is where the building stops:
>
>~~~
>x_file.c:1062:13: error: implicitly declaring library function 'snprintf' with 
>type 'int (char *, unsigned long, const char *, ...)' 
>[-Werror,-Wimplicit-function-declaration]
>snprintf(destfile, MAXPDSTRING, "%s/%s", destination, filename);


that's fixed in 'devel' (I forgot the PR/issue that reported this, but there's 
one)


mfg.sfg.jfd
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Question about prepping Scheme for Pure Data external for Deken?

[IOhannes m zmölnig]

On 7/12/21 23:51, Iain Duncan wrote:

Hi folks, I'm able to spend some time on Scheme for Pure Data again over
the next couple of weeks, and just wanted to check on what I need to have
done to make it easy to install through Deken. For Max, I had to have
successfully compiled binaries for Mac, Windows 32, and Windows 64. Is it
the same for Pd? I assume Linux users will get things either by compiling
from source or a a linux package manager?


yes and no.

i do my best to package the entire Pd world for Debian (and 
derivatives), but due to the nature of distributions, these packaes of 
lag behind.


so most deken packages will also include a number of Linux variants.
to get yourself a feeling how this is typically handled, just search for 
your favourite package (e.g. "zexy") on deken, and see which 
architectures are available (you might want to turn off the "Hide 
foreign architectures" in the deken-preferences)


fgndsr
IOhannes



OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] signal graph processing

[IOhannes m zmölnig]

On 4/28/21 18:49, David Rush wrote:

Hi All -

I'm trying to figure out where to look in the code to try and understand
the signal rate processing better. Specifically, I want to understand how
the graph gets optimized - I've read a rumour that [*~ 0] can cause a whole
signal chain to stop being computed,
and I would like to verify that in the
code and understand the whole process a bit better.


don't listen to rumours. they are often wrong (like this one)

(and it wouldn't make sense: feeding a 0-signal into an object doesn't 
necessarily mean that that object will also output zeros)




Where should I start looking?



the core of the DSP-graph handling is in src/d_ugen.c


ngsar
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] multi-architecture deken packages

[IOhannes m zmölnig]

On 4/15/21 18:26, Alexandre Torres Porres wrote:

Thanks for all the clarifications, it's still hard for me to follow it all,
but I think I got the most of it :)

Bottom line, we gotta test a RPi with binaries for armv6 and armv7,  if no
significant improvement is found on armv7 (and there might not be), let's
just ship armv6.


yes.



The only issue is that deken might not give the armv6 option for armv7. 


why would it not?
since armv7 is backward compatible with armv6, deken will offer to 
install either of the two architectures if it believes that it is 
running on armv7.

(and it will only offer armv6 if it believes that it is running on armv6)


But
the funny part is that most people with a RPi 3 and stuff end up getting
armv6 instead anyway :) not sure what to do about that. Hopefully this
information for RPi users can be easily found.

alternatively: find some simple enough code to do runtime detection of 
the actual arm CPU.


gfSDR
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] multi-architecture deken packages

[IOhannes m zmölnig]

On 4/14/21 23:59, Alexandre Torres Porres wrote:

Em qua., 14 de abr. de 2021 às 18:29, IOhannes m zmölnig 
escreveu:


But one can also just ship armv6 and aarch64 and it should work for
everybody, right?


as said before: somebody should do some benchmarking how much gain there
is for armv7 with respect to armv8.



I don't understand because I was talking about *armv6* (Linux-armv6-32) and
*aarch64* (Linux-arm64-32).


the "as said before" was referring to some other mails years ago.
iirc, something that triggered
  https://lists.puredata.info/pipermail/pd-list/2019-06/125453.html



You said it yourself that we should use *armv8* for the 32 bit variant
(Linux-armv8-32), and *aarch64* for this other one. We're also agreeing
*armv8*/Linux-armv8-32 is pointless. So I guess you mean armv8
as (Linux-arm64-32) and *aarch64*.


no. i'm pretty sure i meant 32bit arm architectures.
i think the main concern is the speed-boost between armv6 vs armv7.
the latter has (usually) better support for (single precision) floating 
point math, and might give a significant speed gain when doing signal 
processing.


otoh, it might not be able to fully utilize the additional instruction 
set if there's no explicit code for it (as would be typical for 
pd-extenrals)

(see also http://single-boards.com/armv6-vs-armv7/)

that's why i keep mentioning benchmarks.

the armv7 vs armv8 (aarch32!) debate is basically the same, though i 
guess(!) speed improvements might not be as prominent.





Now, my understanding is that *aarch64* can't run anything else other than
this... can it run *armv6* and *armv7*?


can you run intel/32bit externals on your intel/64bit mac book? yes
can you run intel/32bit externals within your Pd-intel/64bit on that 
same mac book? no


fgmsard
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] multi-architecture deken packages

[IOhannes m zmölnig]

On 4/14/21 22:41, Alexandre Torres Porres wrote:

Em qua., 14 de abr. de 2021 às 16:47, IOhannes m zmölnig 
escreveu:

Now, one thing is weird, cause Eric was using the organelle with deken and
he could only see (Linux-armv6-32) instead of (Linux-armv7-32), is this a
deken issue?


not really.
if you obtained puredata from the raspbian repositories (as opposed to 
the Debian repositories), or compiled it yourself (without paying 
careful attention, using the raspbian provided toolchain - iirc), you 
would get a Pd-armv6.
now Pd reports to deken which architecture it supports, but the code is 
just some compile-time #ifdef magic, and doesn't actually query the CPU 
capabilities.
the net result of this is that Pd tells deken that it supports armv6, 
but not armv7 (or - heaven forbid - armv8) - so that's why you can only 
see arvm6-externals (unless you manually configure deken to use 
"Linux-armv7-32")


see also https://github.com/pure-data/deken/issues/206


But one can also just ship armv6 and aarch64 and it should work for
everybody, right? 


as said before: somebody should do some benchmarking how much gain there 
is for armv7 with respect to armv8.


fgsrasd
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] multi-architecture deken packages

[IOhannes m zmölnig]

On 4/14/21 22:10, IOhannes m zmölnig wrote:


the arch-agnostic extensions (.pd_linux, .pd_darwin, .dll) are often 
used for i386, because in the olden days that was the only extension.

if you happen to run a Pd<<0.40 chances are that you are using a 32bit Pd.


and actually, if you care for older Pd-versions, you should use 
.pd_linux as the extension for Linux/amd64, as .l_amd64 is only 
supported since Pd-0.49 (and we don't want to get back to that 
abomination older versions of Pd would use for that platform).


mfdsf
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] multi-architecture deken packages

[IOhannes m zmölnig]

On 4/14/21 20:08, porres wrote:
>> armv6 = ?? (maybe .pd_linux)
>> armv7 = .l_arm
>> armv8 = .l_arm64
>
> well, yeah, if we have just a package for raspbrry pis, then we can
> pack these 3 together, of course!!!
>
> pd_linux was listed for Linux-amd64-32 (regular 64 bits Linux), so the
> problem would be to pack this with it as well - unless there's
> something else specfic for this architecture.

.pd_linux is the generic externsion for Pd-externals under linux - 
regardless of architecture. Pd on Linux will look for this extension on 
DEC/alpha, RPi/zero, i386 and HAL/9000.
the arch-specific extenion for i386 on linux is (of course) .l_i386 (if 
you've ever encountered a .d_i386 or .m_i386, you might see a pattern).


the arch-agnostic extensions (.pd_linux, .pd_darwin, .dll) are often 
used for i386, because in the olden days that was the only extension.

if you happen to run a Pd<<0.40 chances are that you are using a 32bit Pd.

>
> Anyway,  I guess it makes sense to pack the 3 pi versions together,
> then the 2 linux also together (32/64 bits), then windows in the same
> way (32/64) and the mac fat binary for both 32/64 bits. 4 Packages
> instead of 8!
>

i cannot follow.
why does it make sense to separate by OS? what's the advantage of having 
separate Windows and macOS packages, instead of a single package that 
contains both Windows and macOS binaries?


also, what are the "2 linux (32/64 bits)"?; i currently count "*5* linux 
(32/64 bits)" in this discussion alone.


sidenote: there actually *is* a reason to not lump all the binaries 
together: filename size.
since the architectures are encoded in the filename, and filenames 
typically have a limited length (256 characters on many filesystems!), 
this limits the number of architectures you can possibly have in a 
single deken package.


i stumbled upon this when testing deken.
however, i think in real-world, the deken package with most 
architectures is probably zexy (1*Darwin,2*Windows,4*Linux) which has a 
total filename size of 131 characters.
Adding the missing Darwin/i386 and Linux/armv6 and the legacy 
Darwin/ppc, would give us 182 chars, which still has a bit of headroom 
before becoming an actual problem.



mgdsr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] multi-architecture deken packages

[IOhannes m zmölnig]

this all started as a thread on github:
https://github.com/ericlyon/pd-fftease/issues/45

since i think it is of general interest (and i'm pretty sure i will 
never ever find the relevant info under the "time for a new release? 
(FFTease-3.1)" thread again, i'm taking this discussion here.


the thread mainly revolves around how to create a single deken-package 
that contains binaries for all the relevant architectures.

i'm too lazy to recap it here.

the current discussion state is, how to deal with all those arm-variants 
out there.


if somebody has more insight into the arm architectures, please shed a 
light :-)


::

it's not complicated: the 32bit arm variants `armv6`, `armv7`, `armv8` 
(aka `aarm32`),... are backwards compatible.

- you can run a binary compiled for `armv6` on any `armv7` or `armv8` CPU.
- you can run a binary compiled for `armv7` on any `armv8` CPU.
- but you cannot run a binary compiled for `armv8` on the older `armv7` 
resp `armv6`  CPUs (missing instruction set)
- similarly, you cannot run a binary compiled for `armv7` on the older 
`armv6` CPU.


it's very similar to `i386` and `i686` and `Pentium-i7` and the like.
typically, the newer CPUs will have instruction sets that outperform the 
older CPUs (`MMX/SSE/AVX` on the `x86` platform; `NEON` on `arm`).
however, if you have a modern `Pentium-i7` and you are running an 
`i386`-compatible binary you will probably still get decent performance, 
because the processor is so much faster.
with `arm`-chipsets it is a bit different, as they are much less 
powerful, so you hit the limitations sooner.


@porres wrote:
> I'm confused now, does this mean Raspbian is just for RPi Zero/1?

it means that you can use Raspbian on the RPi Zero/1/2/3 and 4.
however, you will get sub-optimal performance on the RPi2 and above.

if you enable the normal Debian repositories on the RPi, you will get 
into trouble on the RPi Zero/1, as the binaries might (and most likely: 
will) have instructions that the RPi Zero/1 lacks.


> so i'm confused, is the organelle a rasp 1?

it all depends on which version you have. the [current 
specs](https://www.critterandguitari.com/organelle#design-specs) mention 
a `ARM Cortex A53` which is an `aarch64` processor (`armv8`)


@emviveros wrote
> "compute module" are not important since **RPizero variants are 
important**, so armv6 should be disponible.


i'm not sure i understand what you mean.
i tried to say, that i believe that
- "compute module" is not important
- RPi/zero is of (limited) importance
- because of the RPi/zero we probably want to support `armv6`

i guess you are saying the same(?)

and
> My first annoying is how to name armv6, armv7 and armv8 (aarch64) 
binaries to create a unified deken package for arm compilations.


i don't know what this means either.
however, i think we should forget about a unified `arm32` deken package.

> armv6 = ?? (maybe .pd_linux)
> armv7 = .l_arm
> armv8 = .l_arm64


to which @porres answered:
> anyway, let's just have these 3 together and I guess there won't be 
any issues :)




at least for me, `armv8` is not the same as `aarch64`.
most `armv8` are capable of both 32bit (`aarch32`) and 64bit (`aarch64`) 
instruction sets, but the 64bit part is optional.
i'd prefer to use the `armv8` name for the 32bit variant *only*. when 
talking about the 64bit variant, we should use `aarch64`.


regarding `armv6` and `armv7` in a single folder, i'm not sure whether 
this would work:
- if a `Pd-armv7` happens to see the `armv6` external first, it will 
just load it (and never try to `armv7` binary)
- if a `Pd-armv6` happens to see the `armv7` external first, it will 
just try load it: and i think the *loading* would succeed, leading to 
crashes whenever an illegal (armv7-)instruction is encountered.


but as i've written above: the `armv6` is a very limited platform. you 
probably do not want to install any binaries that you cannot use on it 
anyhow. so i'd suggest to cram all the architectures into a fat deken 
package with the exception of `armv6` which you should package separately.



mgfds
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] "int argc" giving weird values

[IOhannes m zmölnig]

On 3/3/21 12:12 PM, Alexandre Torres Porres wrote:

Em qua., 3 de mar. de 2021 às 07:26, IOhannes m zmoelnig 
escreveu:


what's that `t_pd*dummy` supposed to do in the argument list of `del_new`?



no idea, I was trying to copy the structure from x_list.c, it was killing
me that it works that but I'm obviously missing something.


well, "list" is a very special symbol in Pd.
that's why it requires special handling when using it as an object-name.
hence the "t_pd*dummy" hack in x_list.c

(btw, that's also the reason why zexy's  [l] object (aka [lister]) has 
such a stupid (long) name - i just couldn't make it work in a sane way 
with the proper name "list". a good thing this is now, that Pd has a 
[list] object which is slightly incompatible).




It seems that's not what I have to do either. I copied the structure from
x_array.c now and it just doesn't have any t_pd*dummy - other than me ;)


[array] is not a special symbol. that's why it is a working template for 
any such code.



funny that it was all working just fine, it was when I tried to add "flags"
and parse them that things got weird...


i doubt it (that is: iff you also had any arguments)
having that extra "t_pd*" argument shifts the argument-list by 4 bytes, 
making the values invalid.


usually this gets caught by the compiler.
however, since the constructor-functions arguments are established at 
run-time (as opposed to compile-time), the code of Pd and friends is 
full of function-casting, which very efficiently hides such problems.


gmsard
IOhannes




OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] netreceive: listen failed: Address already in use

[IOhannes m zmölnig]

Am 27. Februar 2021 19:22:26 MEZ schrieb Pierre Guillot 
:
> 
> Is it normal?
> 

yes.
this is how networking works.
only a single listener on any given port pet interface.


> I managed to solve this problem by replacing SO_REUSEADDR to
> SO_REUSEPORT
> on the function socket_set_boolopt() (l. 703 of x_net.c). I don't know
> much
> about sockets but I understand that it allows two [netreceive] objects
> to
> use the same address AND the same port. Do you think this is a proper
> way
> of fixing this problem? 

no it's not.
as you've already discovered, this is not supported on all platforms, and those 
platforms that do support SO_REUSEPORT, can (and do) implement it very 
differently.
in most cases it will allow you to bind to the same port multiple times, but 
you will not receive data on all clients.

https://stackoverflow.com/a/14388707

one possible fix for this is to have a single socket that binds to the port, 
that serves all `[netreceive]` instances (using that port). this obviously 
canbonly work if all `[netreceive]` instances live in the same application.

you might also have luck with multicast.


mfg.hft.fsl
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[IOhannes m zmölnig]

On 1/14/21 10:42 AM, Roman Haefeli wrote:


See PR:
https://github.com/porres/pd-fluidsynth/pull/5



given that i consider myself upstream of the original "localdeps.*.sh" 
scripts and those scripts are located under https://git.iem.at/pd/iem-ci 
where they are used by a number of (our, that is: the iem's) libraries, 
i would highly welcome it if you could submit a PR to that central 
location rather than a single one of the consumers of those scripts.


thanks for your consideration.

gfmards
IOhannes



OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[IOhannes m zmölnig]

Am 9. Jänner 2021 18:39:30 MEZ schrieb Alexandre Torres Porres 
:
> 
> What feels sane for me is creating a new object, with a different name
> (fluidsynth~) and its own design that is cleaner and doesn't try to
> fix
> this compatibility issues, cause it's just a nightmare with no simple
> solution. I like the idea of making it more compatible to Pd Vanilla
> and
> take messages in a more straightforward way from its internals, and I
> could
> do that by having that as a default and just removing the "legacy"
> stuff.
> That would make it all much cleaner...
> 
> Anyway, that's how I'm leaning now... what do you people think?
> 

I think this is a good idea.

probably (if simple enough) you could (also) provide an abstraction that 
exposes the original API.

as for the ceamcc version: I think this really should have been avoided.


mfg.hft.fsl
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

[IOhannes m zmölnig]

On 1/8/21 10:16 AM, Roman Haefeli wrote:

I took the liberty to move this over to pd-dev

On Fri, 2021-01-08 at 03:48 -0300, Alexandre Torres Porres wrote:

Em qui., 7 de jan. de 2021 às 20:07, Roman Haefeli <
reduz...@gmail.com> escreveu:

On Thu, 2021-01-07 at 00:14 -0300, Alexandre Torres Porres wrote:


we still need to sort this for linux,


Since you seem you got it sorted (and I figured out how to compile
fluidsynth with no additional deps)


how did that go?


I just updated pd-fluidsynth repo to get your and Lucas' most recent
changes. I didn't have to modify anything for the build process to
work.

~~~sh
cd pd-fluidsynth
make pkglibdir=$HOME/pd-src/workspace/Linux-arm7-32
make pkglibdir=$HOME/pd-src/workspace/Linux-arm7-32 install
cd $HOME/pd-src/workspace/Linux-arm7-32/fluid~
sh linuxdep32.sh
rm linuxdep32
~~~

However, the crucial part is that the included libfluidsynth.so should
not be "tainted" with support for all kinds of things. This means, you
can't take the one shipped by the distro.


  Can you describe the steps and put it in our readme (with a PR)?


You mean what steps were necessary to compile fluidsynth? I didn't have
to do anything suprising or special. I just had  to figure out how to
disable everything by reading the docs about building. This is what I
came up with (I hope it is correct and complete):

~~~sh
git clone https://github.com/FluidSynth/fluidsynth/
cd fluidsynth
mkdir build
cd build
cmake -Denable-libsndfile=off -Denable-jack=off -Denable-alsa=off 
-Denable-oss=off -Denable-pulseaudio=off -Denable-ladspa=off 
-Denable-aufile=off  -Denable-network=off  -Denable-ipv6=off 
-Denable-getopt=off -Denable-sdl2=off ..
make
sudo make install
~~~

After this, I compiled fluid~ with steps from above.
tot
Regarding the makefile of pd-fluidsynth, I don't understand the purpose
of this section:

---
define forLinux

ifeq ($(firstword $(subst -, ,$(shell $(CC) -dumpmachine))), i686)
 datafiles += scripts/linuxdep32.sh
 else
 datafiles += scripts/linuxdep64.sh
endif

endef



---

Depending on which arch is detected, it'll add one or the other script
in the build result. 



that seems all wrong:
why would you want to install one of these script based on the build 
architecture?


apart from that: the linuxdep*.sh scripts seem to be quite bogus.
you  really should evaluate the dependencies of the fluid~.pd_linux file 
to see where these libraries are to be found.
rather than assuming they are installed in /usr/local/lib/ resp 
/usr/local/lib64/ (the latter directory is only used on fedora based 
systems), use `ldd`.
this will allow you to get libraries from /usr/lib/, 
/usr/local/lib/i386-linux-gnu/ or wherever your dynamic linker would 
take the libfluidsynth-library from.




I think what this is meant to do is to _execute_
the arch specific script, so that libraries get included. I'm not yet


if you follow my advise, there is no need to use *arch* specific scripts 
(you need different scripts for different dynamic linking mechanisms, so 
that's why my original scripts are for windows (dll), macOS (dylib),...; 
but there's no need for the scripts to be aware of the CPU-type - as 
long as you use the system provided tools to resolved dependencies.



familiar with makefiles to tell you just right away how this is done,
but according to the snippet, I'd suppose something like this:

---
define forLinux

ifeq ($(firstword $(subst -, ,$(shell $(CC) -dumpmachine))), i686)
 $(shell /bin/sh scripts/linuxdep32.sh)
 else
 $(shell /bin/sh scripts/linuxdep32.sh)
endif



now there are a couple of things with this:
- first you don't need the complicated architecture evaluation, if you 
do the same thing regardless of the result
- then, there is no proper definition *when* the script is run. 
basically it is run whenever you execute `make`, even if you run e.g. 
`make clean`.
- finally, the collection of dependencies should *never* be part of the 
ordinary build process (`make`, `make all`, `make install`, `make 
uninstall`, `make clean`,...).
if you think you *must* include the code in the Makefile, then it should 
be a separate target, that is only called explicitely, e.g. via

`make installdependencies`.

most likely, this should be a post-install operation (respecting DESTDIR 
and similar variables).



for the sake of simplicity, i would do something like:

~~~
install+dependencies: install
./scripts/dependendencies "${installpath}" "${extension}"
~~~

in in ./scripts/dependencies search all files with the 
${extension}-suffix in "${installpath}" and run an OS-dependent script 
on them.



gfmdsar
IOhannes



OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] PD 0.51-4 bug fix candidates

[IOhannes m zmölnig]

On 12/20/20 10:34 AM, Dan Wilcox wrote:

 This could be changed via adding a couple make targets which call tcltk-wish.sh to 
download & build and we can set the Tk version number in the Makefile and/or 
configure.
just make sure that the default build process does not require any 
network access.


gfds
IOhannes



OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] PD 0.51-4 bug fix candidates

[IOhannes m zmölnig]

On 12/9/20 8:50 PM, Dan Wilcox wrote:

Howdy all,

As quickly discussed on GitHub, there are a couple bugs which may warrant a 
0.51-4 release.

In addition, here is a little list of things I think would be good fixes to 
have:

windows: save-to-/tmp/foo.wav bug


+1



networking & libpd: getaddrinfo() rejects dual stack socket settings on BSD and 
Android (https://github.com/pure-data/pure-data/pull/1232 
)


+2



mac: update patch window size after configure 
(https://github.com/pure-data/pure-data/pull/1236 
)


+1



multi-instance & libpd: set pd_this for readsf~ and writesf~ threads 
(https://github.com/pure-data/pure-data/pull/1227 
)


+2



writesf~: fix infinite loop on I/O error 
(https://github.com/pure-data/pure-data/pull/1224 
)


+10



mac: add back-ported patch for Tk 8.6.10 which fixes disabled Help menu items 
(https://github.com/pure-data/pure-data/pull/1226 
), note: requires re-building 
and packaging Wish.app in mac/stuff


+1
==
17



should we prepare and merge this into 'develop', or does miller wants to 
merge them separately?



gfmadsr
IOhannes



OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] [PD-announce] Pd 0.513 test5 released

[IOhannes m zmölnig]

Am 3. November 2020 15:37:38 MEZ schrieb Dan Wilcox :
> Main point is that the 64 bit build needs the 64 bit Tk.

sorry for being dumb, but: why?

I agree that its probably preferred to have matching architectures between 
Pd-core and Pd-GUI, but is it a requirement?

afaict the problem lucarda is describing comes mostly from the fact that 
wish.exe and pdfontloader.dll have different archs. (or is this what you were 
saying).


mfg.hft.fsl
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] pdmax with settable sampling rate

[IOhannes m zmölnig]

Am 27. September 2020 01:58:03 MESZ schrieb "João Pais" :
> Hello list,
> 
> the current version of pdmax only

what's "pdmax"?
how does it differ from [pd~] compiled for max/msp? more to the point: is the 
issue you are raising here specific to the max/msp-object, or is it a [pd~] 
issue on all platforms?

>  This would
> allow for the same patch to be used with different sampling rates.

would it?
at least with a Pd-host, the actual sample rate would be determined by the host.
So while the child process might believe that it is running at (say) 96kHz, if 
the host runs at 44.1kHz the child would still only process 44100 samples per 
second (and channel).




mfg.hft.fsl
IOhannes


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] tcl error message

[IOhannes m zmölnig]

On 2020-06-30 23:57, Eric Lennartson wrote:
> Got this error while making an abstraction. Only happens when I load the
> patch as an abstraction, not when I open the file itself. Pd seems to
> continue functioning normally, but I figured that y'all might want to know
> about it. Not sure what else might be helpful to know.

looks like the well-known problem with changing the appearance of
iemgui-objects in a closed subpatch/abstraction.

e.g.
[inlet]
|
[number $1(
|
[hradio]

gfmdsar
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Macs to transition to ARM processors

[IOhannes m zmölnig]

Am 22. Juni 2020 23:24:04 MESZ schrieb Dan Wilcox :
> Howdy all,
> 
> Apple announced today that it will transition from Intel to its own
> Arm processors.

oh.
i thought they made that switch in 2007.

> What this will bring is:
> 
> * Universal 2: x86_64 & arm fat binaries
> *
> 
> Building Pd itself for macOS arm should be relatively easy, just a
> different arch target. For externals, this would may require an
> additional fat lib type, perhaps dfat_2? Note, I believe the
> distinction will be important for us since we still have "Universal 1"
> builds. 

hmm. why?
the original d_fat externals for Pd won't run on modern mac(hine)s at
all, as they contained ppc and i386, which are both unsupported these days.
yet the file format ( the container) stays the same, and it is totally
possible to have a d_fat that runs on ppc, ppc64 (an arch that was never
officially supported by PD), i386 and x86_64, so running on all
architectures ever supported by OSX (modulo system libraries...).
why not just add arm64 to that list?

so initially, I was going to rebuke the idea oft a d_fat2 format.

apple's labelling as "Universal 2" is a bit concerning though...

anyhow, I don't really see why apple should make a 2nd universal format.
iirc, "fat" is a technology from NextStep, so its well aged, and has
proven itself.
this of course is no reason to not drop it.

more important: can you (well: they) make money with a new format?
i'm having a hard time here to imagine how (but then: i'm not very good
in imagining how to make money in general).

i don't think there are still enough ppc users left for apple to care
about them.
thinkgs might be different with i386 though.

however, i guess the biggest issue is for the developers it's getting
really hard to create fat binaries that cover more architectures than
x86_64 and i-arm64.
that's because there's no reasonable toolchains available that allow you
to do so.
to build binaries for the new arm architecture, you probably need
XCode12, which - like XCode10 and XCode11 - won't support x86_64 (and
PPC has been dropped around XCode4, if my wikipedia foo is correct).
so the only way to produce fat binaries (that include mor ethan x86_&4
and amd64) is to have multiple build systems (parts of them unsupported
by now) and combine the artifacts into a single binary in a second step.

that sounds like a big enough hurdle to be a rather plump nudge for most
applications to support only "recent" architecture. no need to invent a
new format.

fgmasd
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] 64-bit vs 32-bit info

[IOhannes m zmölnig]

to answer martin's question: deken will print platform information at
startup time, albeit the printout is only visible if you raise the
verbosity in the Pd-console.

something like:
> [deken] Platform detected: Linux-x86_64-float32
> [deken] Platform re-detected: Linux-amd64-float32

this is basically the information you asked for, with a few caveats:
- if you clear the Pd-console, the printouts are gone.
- there's some naming inconsistency (e.g. in the example above you see
both "amd64" and "x86_64" which is really the same.
- it might be confusing to see *two* lines with essentially the same
information.

the first line is the result of an architecture detection on the
GUI-side. however, the GUI might have a *different* architecture than
the Pd-core (and the latter matters when it comes to loading externals).
therefore the Pd-core sends its architecture to the GUI as well,
triggering the 2nd output.

i guess the printout could be improved, i'm open to suggestions.

On 5/28/20 7:22 PM, Christof Ressi wrote:
> I have some cross-platform CPU architecture detection code which I code
> port to Pd, so that we could have more descriptive error messages.

hmm, i don't think *that* is the problem here.
it's quite clear which binaries Pd can load at compile time (as is
reported by the 2nd line in the deken initialisation; see above)


but i think your idea is to improve the error message along the lines of:
> failed to load foo.dll (the library is 32bit, but Pd is a 64bit process)

the trivial part is the 2nd one ("this Pd is 64bit").
the more complicated part is the first one, as it requires to actually
open the file that dlopen()/LoadLibrary() could not open and inspect the
binary data to understand the architecture of the blob.

the deken cmdline utility can do this, but it utilizes several
specialized libraries for the task.
i think embedding such libraries into Pd would be an overkill for the
problem.

mgasf
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] compiler oopses compiling s_net.c on windoze

[IOhannes m zmölnig]

On 5/28/20 4:37 PM, Christof Ressi wrote:
>> which is the newest
>> version I have.
> You might want to consider an upgrade ;-)

note that the cross-compilers compile newer versions of Windows just fine.
they just have a very conservative default setting.

gfamdsr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] compiler oopses compiling s_net.c on windoze

[IOhannes m zmölnig]

On 5/28/20 1:49 PM, Christof Ressi wrote:
> @Miller: are you compiling on a Windows XP machine !?

no. he is cross-compiling.

on my system (Debian/sid, Mingw-7.0.0, gcc:9.3-win32), i had the same
problem (that's why i had the answer ready):

compiling the following source with the cross-compiler:

~~~
#include 
int main() {
#ifdef WINVER
  printf("WINVER=0x%X\n", WINVER);
#endif
#ifdef _WIN32_WINNT
  printf("_WIN32_WINNT=0x%X\n", _WIN32_WINNT);
#endif
 return 0;
}
~~~

prints:
_WIN32_WINNT=0x502

(for both i686 and x86_64)

> The #ifdefs would fix the compilation error on Windows XP, but we still
> have to compile the release on a Windows Vista+ machine to make the IPv6

that's why i proposed *both* fixes (the ifdefs and raising the WINVER)

> On macOS, the minimum supported version is 10.6, which is from 2009.
> Windows XP was first released in 2001...

although i think that these days more people are using XP than OSX-10.6

> 
> We might still allow people to compile for Windows XP by overriding
> WINVER, but it shouldn't be the default anymore.

+1.

there should be a configure option to select the WINVER from the cmdline.

gadsr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] compiler oopses compiling s_net.c on windoze

[IOhannes m zmölnig]

On 5/28/20 7:14 AM, Miller Puckette via Pd-dev wrote:
> Compiling on Windows using mingw32 I get this:
> 
> x86_64-w64-mingw32-gcc -DPACKAGE_NAME=\"pd\" -DPACKAGE_TARNAME=\"pd\" 
> -DPACKAGE_VERSION=\"0.51.0\" -DPACKAGE_STRING=\"pd\ 0.51.0\" 
> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"pd\" 
> -DVERSION=\"0.51.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 
> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 
> -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 
> -DLT_OBJDIR=\".libs/\" -DSTDC_HEADERS=1 -DHAVE_FCNTL_H=1 -DHAVE_LIMITS_H=1 
> -DHAVE_MALLOC_H=1 -DHAVE_STDDEF_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 
> -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMEB_H=1 
> -DHAVE_UNISTD_H=1 -DHAVE_ALLOCA=1 -Dvfork=fork -DHAVE_STDLIB_H=1 
> -DHAVE_MALLOC=1 -DHAVE_STDLIB_H=1 -DHAVE_REALLOC=1 -DRETSIGTYPE=void 
> -DHAVE_DUP2=1 -DHAVE_FLOOR=1 -DHAVE_GETCWD=1 -DHAVE_GETTIMEOFDAY=1 
> -DHAVE_MEMMOVE=1 -DHAVE_MEMSET=1 -DHAVE_POW=1 -DHAVE_SQRT=1 -DHAVE_STRCHR=1 
> -DHAVE_STRERROR=1 -DHAVE_STRRCHR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOL=1 -I.  
> -I../portaudio/portaudio/include -I../portmidi/portmidi/pm_common 
> -I../portmidi/portmidi/porttime -DWISH=\"wish86.exe\"  -g -O2 -ffast-math 
> -funroll-loops -fomit-frame-pointer -O3 -MT pdsend-s_net.o -MD -MP -MF 
> .deps/pdsend-s_net.Tpo -c -o pdsend-s_net.o `test -f 's_net.c' || echo 
> './'`s_net.c
> s_net.c: In function 'addrinfo_get_list':
> s_net.c:55:22: error: 'AI_ALL' undeclared (first use in this function); did 
> you mean 'SIF_ALL'?
>  hints.ai_flags = AI_ALL |   /* both IPv4 and IPv6 addrs */
>   ^~
>   SIF_ALL
> s_net.c:55:22: note: each undeclared identifier is reported only once for 
> each function it appears in
> s_net.c:56:22: error: 'AI_V4MAPPED' undeclared (first use in this function); 
> did you mean 'MIDI_MAPPER'?
>   AI_V4MAPPED |  /* fallback to IPv4-mapped IPv6 addrs */
>   ^~~
>   MIDI_MAPPER
> make[2]: *** [Makefile:2318: pdsend-s_net.o] Error 1
> 
> 
> I'l try to fix this Thursday but if anyone who understands the new networking
> code gets there before I do you might do a better job than I can...


it's easy: AI_ALL and AI_V4MAPPED are only available since Windows Vista.

the default settings compile for Windows2000 (or so).

to compile for windows vista (and aboce), use the following macros
(preferably in the Makefile):
> -DWINVER=0x0600 -D_WIN32_WINNT=0x0600

(this is already done in the autotools-Makefile; but afaik not in the
src/makefile.mingw)

alternatively (and probably additionally), the use of these macros
should probably be protected by ifdef clauses.

in iemnet (which has backported some of the new code from s_net.c) i use:

~~~
  hints.ai_flags |= AI_PASSIVE
#ifdef AI_ALL
| AI_ALL /* both IPv4 and IPv6 addrs */
#endif
#ifdef AI_V4MAPPED
| AI_V4MAPPED /* fallback to IPv4-mapped IPv6 addrs */
#endif
| 0;
~~~

mgfrdsa
IOhanne



signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] netsend/netreceive less printout?

[IOhannes m zmölnig]

On 5/22/20 6:30 PM, Miller Puckette via Pd-dev wrote:
> To Pd dev -
> 
> Any reason I can't suppress the "listening on" and "connecting to" messages
> from netreceive and netsend?  I think they're unnecessary and it's often
> necessary to close and open connections frequently since only one of them
> may have any given connection point and frequently you have to use it to send
> out to more than one remote machine.

i agree that these should only be printed out at a higher verbosity level.
i've pushed according changes to the `update/0.51` branch (which also
has a few other minor thingies)

https://github.com/pure-data/pure-data/pull/1014

gmdsr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] Cross compiling Pd

[IOhannes m zmölnig]

On 5/10/20 4:40 PM, Max wrote:
> 
> ./configure --host=arm-linux-gnueabi-gcc

you are passing the compiler as the target-architecture.
not going to work.

> 
> this results in:
> checking host system type... Invalid configuration
> `arm-linux-gnueabi-gcc': machine `arm-linux-gnueabi' not recognized
> 
> with
> ./configure --host=arm-linux
> it goes a bit further
> 
> 
> checking host system type... arm-unknown-linux-gnu
> checking for arm-linux-gcc... no

so you passed "arm-linux" as the target-arch and configure looks for a
compiler named "arm-linux-gcc".
you know that your compiler is arm-linux-gnueabi-gcc. does that ring a bell?

> surely there is something obvious I am missing here.

./configure --host=arm-linux-gnueabi


also, rather than exporting envvars (CC, CFLAGS), you should probably
pass them as flags to configure:

./configure --host=arm-linux-gnueabi CFLAGS="-march=armv7+simd"

(no need to set CC, as configure does that for you via the "--host"
flag. passing CFLAGS as argument will make it local to the build-toolchain)


gfsadr
IOhannes

PS: all of the above is not specific to Pd, but applies to virtually all
autotools projects; remember it if you intend to cross-compile other stuff.



signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] PD-specific tips for compiling faster on Windows

[IOhannes m zmölnig]

On 4/22/20 4:18 PM, Christof Ressi wrote:
>> One danger I'd like to avoid is all of the Windows people *not* using
>> the autotools build as then we lose testing and further updates on
>> that platform.
> That danger is very real :-) I would definitely prefer CMake over
> autotools.

i think CMake is an abomination.

i'm obviously biased though.

gamdsr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev