Re: [PD] hid objects on linux/mac/win? hidraw on linux? hidraw parsing?

[Albert Rafetseder]

Dear Peter & all,


On Linux I can install [hidraw] 0.1.0 via Deken. The external loads
without errors, but I am not getting any response clicking the
"listdevices" message.


As Lucas reported in the other thread, this works just fine for me. (Do 
you see any USB devices, HID or not, when you `lsusb -v` on the command 
line?)





Colleagues have tried to find [hid] for their newer apple cpu's
without success unless they start Pd under the Rosetta emulation and
install Albert's amd64-32 package.


Good to know, and sorry for making you depend on Rosetta. I don't have 
much time to finally get the build system for [hid] updated, nor have 
access to Apple Silicon. Some kind soul on this list even offered to 
compile things for me -- I've gotten nowhere with the required thinking 
and coding since, I apologize!





Interestingly there exists a hid Deken package for Darwin-arm64-32
http://deken.puredata.info/library/hid/0.1.0
but it is not displayed in Pd's built-in search engine on OS X as far 
as

I can remember (maybe someone can check this?).


Deken on pd 0.52.1 (a self-built version IIRC) on Linux, when configured 
to *not* hide packages for foreign platforms, gives me this:


hid[v0.1.0](Darwin-arm64-32).dek
Uploaded by critapec @ 2022-11-09 00:32:28


On Windows there is only [hidraw], correct?


At least there is no [hid]. The sources and makefile include mentions of 
"cygwin", but I don't have a Windows machine either. Even if I could 
build it with mingw, I couldn't test.





General question:
What would be a reason to prefer [hidraw] over [hid]?


Quoting a previous thread on this list, 
https://lists.puredata.info/pipermail/pd-list/2022-11/131618.html


"""
My comparison AFAICT (from working on [hid] a little [...]):

[hidraw]
* is more cross-platform, including Windows
* has a way more modern code base and build system
* offers less "semantic" output -- in the sense that [hidraw] gives you
event codes that you process in your patch yourself, whereas [hid]
decodes many of the possible button presses and other events
* uses an external library, libusb/hidabi, for its functions -- [hid]
only uses OS functions and headers iirc
"""

The mail goes on to suggest the creation of a wiki page "or other 
documentation item [...] listing the different possibilities of working 
with USB HID devices in Pd."


I sat down and tried my hand at this, what do you think? 
https://puredata.info/Members/albert/USB


Suggestions welcome, both content-wise and in terms where to best put 
this.





How do I parse the output of [hidraw]?


My own dabblings with [hidraw] have followed this approximate path:
* Try to get data off the USB device at all
* Then play around and see what values the different buttons, knobs, 
 will send
* Construct a patch to translate from raw HID data to useful Pure Data 
control lines.


Best regards,
  Albert.



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] open multiple files limits?

[Albert Rafetseder]

I'd suggest to open a ticket on GitHub!


Remmy: I can help with that if you like.


Sorry, I missed that it's already here: 
https://github.com/pure-data/pure-data/issues/2170




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] open multiple files limits?

[Albert Rafetseder]

(CC: Remmy, not sure if on the Pd mailing list)


looks like there's a size limit for the callback message.


...and it's around 4 kilobytes, from a quick test with 
very-long-filename-files and the [openpanel] help patch which [print]s 
the result of [openpanel].


I see one OK and three bad results, depending on the combined length of 
filenames (which I measure from the output of [print] in the console, 
i.e. everything after "print: list "):


* Up to 4069 (sic!) characters, everything is fine. [openpanel] prints 
all filenames.

* At 4070, [openpanel] does not [print] anything.
* Above 4070, I get an error message with just the part of the filename 
exceeding 4070 characters, like "a: no such object".
* For yet larger values, I get an error message "float: no such object". 
(Didn't yet bisect the concrete value, 4260 sure triggers it.) Are the 
error messages length-limited as well? :-)



I'd suggest to open a ticket on GitHub!


Remmy: I can help with that if you like.





Christof


On 11.01.2024 15:20, Remmy Canedo wrote:

Hello,

I'm trying to open 189 files with

[bang(
|
[openpanel 2]

file names are 1.wav, 2.wav, 3.wav... 189.wav with different sizes 
from 48,2 to 343,5 KiB


when I use short paths, like home/user/Music/test_samples I'm able to 
open 112 files
with long paths, for ex: 
home/user/FOLDER_1/Folder_002/Folder_3/folder_4/folder_5/test_samples 
I can only open 53 files max.

more than that, it gives me an error in console:
av: no such object

If anyone can explain why this happens and how to overcome these 
limits I would be very grateful.


thanks in advance!
remmy

Pd version 0.52.1
System:
Kernel: 5.15.0-91-lowlatency x86_64 bits: 64 compiler: gcc v: 11.4.0 
Desktop: Xfce 4.18.1
tk: Gtk 3.24.33 wm: xfwm dm: LightDM Distro: Linux Mint 21.2 Victoria 
base: Ubuntu 22.04 jammy









___
Pd-list@lists.iem.at  mailing list
UNSUBSCRIBE and account-management 
->https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] 2D radio buttons object or abstraction?

[Albert Rafetseder]

Before reinventing the wheel: does anyone know of a library that would
contain something akin to radio buttons but in 2D?


I don't, though I'd be interested too.

If you can make do without a visible grid of buttons, and deduce button 
presses from coordinates on a plane instead, the available 2D / xy 
sliders + a bit of dividing/rounding could work:


* xyslide: 
https://forum.pdpatchrepo.info/topic/8656/xy-slider-controls-two-variables-at-once
* xyz-slider: 
https://forum.pdpatchrepo.info/topic/13818/xyz-slider-3-d-slider-using-mouse-scrollhweel
* xy controller using data structures: 
https://forum.pdpatchrepo.info/topic/2699/xy-control
* Forum thread full of useful links: 
https://forum.pdpatchrepo.info/topic/10854/xy-abstraction-to-get-mouse-click-and-drag-coordinates-vanilla

* ...including in particular ELSE/slider2d

Best,
  Albert.



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] http get/post request in pd. how to?

[Albert Rafetseder]

Hello Tobias,

Thank you… but I really can not find out  how to open/install .dek 
files with deken in pd 0.53…

How can I do that?


Exactly as IOhannes describes it:


1. Open the deken dialog


(I.e.: in the "Help" menu, click "Find externals")


2. Open the File->Install DEK file... menu
3. Select a .dek file
4. Click on "Open"

Or similar, I'm currently afk.



Just in case, this is how it works in Pure Data 0.52.1:

1. In the "Help" menu, click "Find externals"
2. The "Find externals" window opens. Click the "More..." button in the 
bottom-right corner

3. A menu opens. Click the "Install DEK file..." button
4. A file browser opens. Choose your DEK file here.

Best regards,
  Albert.



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] some gui objects with grey background in help patches?

[Albert Rafetseder]

Hi,


Hi, I just noticed that in 0.53.0 help patches (eg. testtone.pd) some
GUI objects like toggle or bang appear with grey backgrounds instead of
the default white ones. Is this a bug or a specific feature of the
overhauled documentation?


I guess it's a feature, judging from e.g. 
https://github.com/pure-data/pddp/issues/63 which is titled "Add a 
little bit more GUIs (bang buttons instead of 'bang' messages) and color 
into the help patches."


(I wasn't involved, just found this issue on GitHub.)

Best regards,
  Albert.



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] hidraw v0.1.0 released.

[Albert Rafetseder]

Just tested hidraw on my linux laptop (latest deken version)

Strangely, when I click [listdevice( message in help file, i get in 
console the same device listed 14 times :

(...)

I've seen some same devices appear 2, 3 or 4 times. Not sure why is
this happening but is related to https://github.com/libusb/hidapi. I
just use their function to list devices.


This should be fine. Indeed, ...


eventually you can check that "Usage (page):" is different in each
dup. not sure what this means or how to use it.


Some explanatory snippets:

"""Usages are part of the HID Report descriptor and supply an 
application developer with information about what a control is actually 
measuring or reporting.""" (from 
https://www.usb.org/sites/default/files/hut1_3_0.pdf )


"""HID devices exchange data with the host computer using data bundles 
called “reports”. Each report is divided into “fields”, each of which 
can have one or more “usages”. In the hid-core, each one of these usages 
has a single signed 32 bit value.""" (from 
https://www.kernel.org/doc/html/v5.6/hid/hiddev.html#the-hiddev-api )


E.g., [hidraw] shows two entries for my USB mouse, with:
* Usage (page): 0x2 (0x1), making it a "Mouse" from the "Generic Desktop 
Page".

* Usage (page): 0x1 (0x1), making it also a "Pointer" from the same Page

(My laptop's touchpad produces a dozen or so list entries as well. It's 
a Mouse, a Pointer, a Digitzer for Fingers, and Vendor-Defined ... :-)


By the way, Linux's `lsusb -v` shows similar information to 
[listdevices(--[hidraw]


Best regards,
  Albert.



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] hidraw v0.1.0 released.

[Albert Rafetseder]

Thanks Lucas! What is the use case compared to existing [hid] 
externals?


+1 thank you, a really cool project!

My comparison AFAICT (from working on [hid] a little [1]):

[hidraw]
* is more cross-platform, including Windows
* has a way more modern code base and build system
* offers less "semantic" output -- in the sense that [hidraw] gives you 
event codes that you process in your patch yourself, whereas [hid] 
decodes many of the possible button presses and other events
* uses an external library, libusb/hidabi, for its functions -- [hid] 
only uses OS functions and headers iirc


Maybe we should prepare a wiki page or other documentation item at some 
point listing the different possibilities of working with USB HID 
devices in Pd.


Best,
  Albert.

[1] https://gitlab.com/albert/pd-hid (I'm currently working on using 
pd-lib-builder instead of the old bespoke makefile)




best, P

* Lucas Cordiviola  [2022-11-03 02:04]:

Hi all,

The hidraw external reads raw bytes from hids.

You can find it on Deken for most OSs.

You have to build yourself for very old rasperry-pi's or new M1 or M2 
macs.


Sources are at 
https://github.com/Lucarda/pd-hidraw/releases/tag/v0.1.0


--
Deken Web: https://deken.puredata.info/results.html?name=hidraw

--


Lucarda.

--
Mensaje telepatico asistido por maquinas.




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

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Reading/writing a HID device current best practice?

[Albert Rafetseder]

Thanks Alexandre! Who am I to disagree? ;-)

OK, I'll admit, I started yesterday to port [hid] to pd-lib-builder 
because I've been wanting to learn that anyway. Phil indicated to me 
that he has found a solution other than [hid], so there is no rush.


Nevertheless, I'm totally fine if you go ahead, progress is made, and 
[hid] becomes available to Apple Silicon users faster.


Best regards,
  Albert.

Am 07.09.2022 02:34, schrieb Alexandre Torres Porres:
it would be great to update this project to use pd-lib-builder as it'd 
make

it quite easy to build for apple silicon. I could do that

Em ter., 6 de set. de 2022 às 12:32, Albert Rafetseder <
albert.rafetse...@univie.ac.at> escreveu:


Hi Phil,

Peter beat me to pointing out Deken (thanks!), but I can add:

I put that version on Deken, minimally updated from Hans's original to
build on the Mac laptop I was using then. I put the sources here:
https://gitlab.com/albert/pd-hid

I don't own a macOS/Apple Silicon machine, but I'm happy to 
collaborate

and contribute the little that I know about [hid] and building Pd
libraries. If you like, we can talk more, e.g. here:
https://gitlab.com/albert/pd-hid/-/issues/4

Best regards,
   Albert.

Am 04.09.2022 19:59, schrieb Philip Stone via Pd-list:
> Ah, I had checked Deken, but missed this, since I’m on a Silicon Mac.
> I will look into it to see if maybe I can compile a version.
>
> Thanks, Peter!
>
>
> Phil
>
> Date: Sun, 4 Sep 2022 10:27:37 +0200
> From: "Peter P."
> peterpar...@fastmail.com<mailto:peterpar...@fastmail.com>
>
>
> Hi Phil,
>
> A search on Deken
>
http://deken.puredata.info/search.html?libraries=hid==
> brings up some results which might depend on the OS you are using.
>
> * Philip Stone via Pd-list  [2022-09-04 00:14]:
>> Hello all,
>>
>> I?m wondering what the current best course of action is for
>> interfacing with a HID device in Pd. The older libraries from Hans
>> don?t seem to be maintained; may I ask if anyone has any current
>> experience with Pd and HID?
>>
>>
>> Thanks,
>>
>> Phil Stone
>> Davis, CA



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Reading/writing a HID device current best practice?

[Albert Rafetseder]

Hi Phil,

Peter beat me to pointing out Deken (thanks!), but I can add:

I put that version on Deken, minimally updated from Hans's original to 
build on the Mac laptop I was using then. I put the sources here: 
https://gitlab.com/albert/pd-hid


I don't own a macOS/Apple Silicon machine, but I'm happy to collaborate 
and contribute the little that I know about [hid] and building Pd 
libraries. If you like, we can talk more, e.g. here: 
https://gitlab.com/albert/pd-hid/-/issues/4


Best regards,
  Albert.

Am 04.09.2022 19:59, schrieb Philip Stone via Pd-list:

Ah, I had checked Deken, but missed this, since I’m on a Silicon Mac.
I will look into it to see if maybe I can compile a version.

Thanks, Peter!


Phil

Date: Sun, 4 Sep 2022 10:27:37 +0200
From: "Peter P." 
peterpar...@fastmail.com



Hi Phil,

A search on Deken
http://deken.puredata.info/search.html?libraries=hid==
brings up some results which might depend on the OS you are using.

* Philip Stone via Pd-list  [2022-09-04 00:14]:

Hello all,

I?m wondering what the current best course of action is for 
interfacing with a HID device in Pd. The older libraries from Hans 
don?t seem to be maintained; may I ask if anyone has any current 
experience with Pd and HID?



Thanks,

Phil Stone
Davis, CA




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Design / Philosophy principles behind Pd development

[Albert Rafetseder]

Hi Jérôme,

Likewise!

> A pd patch must be run in old computers. Is it related to the choice
> of C Language and Tcl TK ? Could be also related to some ecological
> vision about new technologies obsolescence and anti-productivism ?

What I understand from one of Miller's papers relates (somehow) to the
"old computers" part. My summary: In the 1980's, GUI and sound
generation used to be separate partly because the computers were not
powerful to do both at the same time, and partly because people built
upon existing designs that were split like that.

(See pages 6 and onward in "Max at Seventeen",
http://msp.ucsd.edu/Publications/dartmouth-reprint.pdf )

The same paper probably answers aspects of your question about MUSIC and
Max Mathew as well. (See page 2.)



> The number of lines of code must be less than 10 000 ?

Another paper by Miller mentions 100k for a version of Max, and
indicates the same limit should apply to Pd: "[...] at 100,000 lines of
code, Max/FTS was approaching the limit of maintainability."

(This is on page 5 of "The Deadly Embrace Between Music Software and Its
Users", http://msp.ucsd.edu/Publications/pdf_EMS14_puckette.pdf )

The current number of source lines of code per the `sloccount` utility
is 118,532 across all programming languages. C accounts for about 85% of
that. More details below.

Best regards,
  Albert.

8<

$ sloccount --version
2.26
$ git branch --verbose
* master bad155d2 oops, version number to 0.52-1 (forgot to fold in the
last 'develop' fixes and now can't rename 0.52-0)
$ sloccount .
[...lots of setup messages omitted...]
Categorizing files.
Finding a working MD5 command
Found a working MD5 command.
Computing results.


SLOCDirectorySLOC-by-Language (Sorted)
73275   src_top_dir ansic=73275
19223   portaudio   ansic=16072,cpp=3108,sh=43
8678tcl tcl=8671,sh=7
6850extra   ansic=6850
4926portmidiansic=4888,sh=38
4169m4  sh=4169
548 mac sh=548
470 msw sh=470
202 doc ansic=202
60  libpd   ansic=60
56  po  tcl=56
44  linux   sh=44
16  md  awk=13,sh=3
15  top_dir sh=15
0   asio(none)
0   autom4te.cache  (none)
0   bin (none)
0   font(none)
0   man (none)


Totals grouped by language (dominant language first):
ansic:   101347 (85.50%)
tcl:   8727 (7.36%)
sh:5337 (4.50%)
cpp:   3108 (2.62%)
awk: 13 (0.01%)




Total Physical Source Lines of Code (SLOC)= 118,532
Development Effort Estimate, Person-Years (Person-Months) = 30.10 (361.19)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 1.95 (23.44)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 15.41
Total Estimated Cost to Develop   = $ 4,066,015
 (average salary = $56,286/year, overhead = 2.40).
SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL.
SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to
redistribute it under certain conditions as specified by the GNU GPL
license;
see the documentation for details.
Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Preset management for Pd Vanilla

[Albert Rafetseder]

Re this half of your email:

> So I'm here to ask what people use in Pd Vanilla, be
> it a pure vanilla solution or an external.

Reporting from a noob-user perspective, I have used acre's ds (data
storage) since it is included in VRR (Virtual Rehearsal Room) for preset
management:

https://git.iem.at/pd/acre/-/tree/master/ds
https://git.iem.at/vrr/vrr

AFAICT, it does what it says on the tin. It saves presets as plain text
files (which I appreciate for versioning), and allows for complex
scenes/programs to be stored, with namespaces and remote control and
everything.

I didn't try to include acre/ds in my own patches yet.


One detail:

> Once you save the patch, the presets you saved get stored in
> the patch.

I think acre/ds handles that differently: You'd do an explicit save into
a separate file that you choose.

> You can check what's up in my repository for more details...
> https://github.com/porres/pd-else/blob/master/Classes/Abstractions/preset.pd

Thanks for sharing, much appreciated!
  Albert.



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] is [hid] dead? can t be 64 bits?

[Albert Rafetseder]

Thank you for the supportive words, everyone!

If you promise to not hold your breath just yet, I can try my hands on
Linux x86 / amd64 / ARM (think: Raspberry) builds as well.

For Windows, I have no idea whether [hid] is even supposed to work, and
have no opportunity to test for the time being. Any hints welcome.

Best,
  Albert.

Am 24/11/20 um 16:54 schrieb mitchell turner:
> Albert,
> Thanks so much for working on [hid] for MacOS. I know there are many that 
> appreciate it.
> 
> — Mitch
> 
> 
> 
> --
> 
> Message: 3
> Date: Tue, 24 Nov 2020 12:02:50 -0300
> From: Alexandre Torres Porres mailto:por...@gmail.com>>
> To: Albert Rafetseder  <mailto:albert.rafetseder...@univie.ac.at>>
> Cc: Pd-List mailto:pd-list@lists.iem.at>>
> Subject: Re: [PD] is [hid] dead? can t be 64 bits?
> Message-ID:
><mailto:caeasfmj+1jr_i6qf9n6kcozz6ed2cnqakkf5vqsl2jf7era...@mail.gmail.com>>
> Content-Type: text/plain; charset="utf-8"
> 
> oh, I had only seen the mail at pd-dev :) nice
> 
> well, this is awesome, thanks! But what about other OSes? Do you need help
> compiling/uploading? Maybe others can help here.
> 
> cheers
> 
> Em ter., 24 de nov. de 2020 às 08:27, Albert Rafetseder <
> albert.rafetseder...@univie.ac.at <mailto:albert.rafetseder...@univie.ac.at>> 
> escreveu:
> 
>> Thank you all for helping me overcome inertia :-)
> 
>>
> 
>> It's my pleasure to present on deken
> 
>>
> 
>> hid[v0.7.3](Darwin-amd64-32)(Sources).dek
> 
>>Uploaded by albert @ 2020-11-24 11:10:37
> 
>>
> 
>> Have fun, and kindly report any errors over at
> 
>>
> 
>> https://gitlab.com/albert/pd-hid/issues 
>> <https://gitlab.com/albert/pd-hid/issues>
>>
> 
>> Cheers,
> 
>>  Albert.
> 
>>
> 
>>
> 
>> Am 19/11/20 um 20:42 schrieb Alexandre Torres Porres:
> 
>>> +1000
> 
>>>
> 
>>> Em qui., 19 de nov. de 2020 às 16:32, Christof Ressi <
> 
>> i...@christofressi.com <mailto:i...@christofressi.com>>
> 
>>> escreveu:
> 
>>>
> 
>>>>> Shall I push it, like, Real Soon Now This Time?
> 
>>>> +1
> 
>>>>
> 
>>>> On 19.11.2020 20:20, Albert Rafetseder wrote:
> 
>>>>>> i dont see it for my mac but older 32bit ones
> 
>>>>>>
> 
>>>>>> is compiling for 64 bits possible?
> 
>>>>> I managed to compile it with minimal tweaks a few months ago:
> 
>>>>>
> 
>>>>> https://gitlab.com/albert/pd-hid/ 
>>>>> <https://gitlab.com/albert/pd-hid/> (sources)
> 
>>>>>
> 
>>>>> Sorry for not pushing the binary to deken yet - I'm all too easily
> 
>>>>> distracted!
> 
>>>>>
> 
>>>>> (Shall I push it, like, Real Soon Now This Time?)
> 
>>>>>
> 
>>>>> Best wishes,
> 
>>>>>   Albert.
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
> 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] is [hid] dead? can t be 64 bits?

[Albert Rafetseder]

Thank you all for helping me overcome inertia :-)

It's my pleasure to present on deken

hid[v0.7.3](Darwin-amd64-32)(Sources).dek
Uploaded by albert @ 2020-11-24 11:10:37

Have fun, and kindly report any errors over at

https://gitlab.com/albert/pd-hid/issues

Cheers,
  Albert.


Am 19/11/20 um 20:42 schrieb Alexandre Torres Porres:
> +1000
> 
> Em qui., 19 de nov. de 2020 às 16:32, Christof Ressi 
> escreveu:
> 
>>> Shall I push it, like, Real Soon Now This Time?
>> +1
>>
>> On 19.11.2020 20:20, Albert Rafetseder wrote:
>>>> i dont see it for my mac but older 32bit ones
>>>>
>>>> is compiling for 64 bits possible?
>>> I managed to compile it with minimal tweaks a few months ago:
>>>
>>> https://gitlab.com/albert/pd-hid/ (sources)
>>>
>>> Sorry for not pushing the binary to deken yet - I'm all too easily
>>> distracted!
>>>
>>> (Shall I push it, like, Real Soon Now This Time?)
>>>
>>> Best wishes,
>>>Albert.
>>>
>>>
>>>
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
>>
>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
>>
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
> 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] is [hid] dead? can t be 64 bits?

[Albert Rafetseder]

> i dont see it for my mac but older 32bit ones
> 
> is compiling for 64 bits possible?

I managed to compile it with minimal tweaks a few months ago:

https://gitlab.com/albert/pd-hid/ (sources)

Sorry for not pushing the binary to deken yet - I'm all too easily
distracted!

(Shall I push it, like, Real Soon Now This Time?)

Best wishes,
  Albert.



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] remote OSC messages

[Albert Rafetseder]

> I tried to connect to the server using netsend, but the console sends me
> this error message:
> "netreceive: listen failed: Cannot assign requested address (99)"

The error is in netreceive, not netsend:

> [listen 7077 vrr.iem.at(
> |
> [netreceive -u -b]

Careful, the second (and optional!) argument following "listen" must be
a hostname or IP address of *your local* machine, not the remote
machine. ("vrr.iem.at" will not work, this is not your machine :-)

See "help netreceive", then open the sub-patch "pd IP version and
multicast" on the bottom-ish right for details.

Best,
  Albert.


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] weird behavior of factorial in expr

[Albert Rafetseder]

Hi Oscar,

> the "fact" (factorial) function does not seem to work properly in the
> "expr" external when called with an argument greater than 12.

the problem in [expr fact(...)] looks like an integer overflow. See [1]
for conceptual details, TL;DR: Factorials produce huge numbers very
quickly, but the implementation of `fact` reserves too little space to
store the result's digits [2], and thus truncates the result, producing
garbage:

[expr fact(12)] is 4.79002e+08, just about right
[expr fact(13)] is 1.93205e+09, clearly *not* the above times 13
[expr fact(14)] is 1.27895e+09, even smaller than the previous result
(...)
[expr fact(17)] is a negative number altogether

I can't comment on the efficiency your implementation as I'm not too
well versed in Pd. I'd speculate it won't suffer [expr fact]'s numerical
problems since AFAIK, patches use floats as the default number format,
basically allowing for larger numbers to be stored.

The usual suggestion for avoiding numerical problems with factorials is
to re-think what the numbers are used for -- Taylor series?
combinatorials of n-choose-k kind? something else? -- and use an
appropriate alternative such as:

* Stirling's approximation [3]
* the Gamma function [4]
* binomial coefficient without factorials [5]

Cheers,
  Albert.

[1] https://en.wikipedia.org/wiki/Integer_overflow
[2]
https://github.com/pure-data/pure-data/blob/2af4b5d/src/x_vexp_fun.c#L913-L928
[3] https://en.wikipedia.org/wiki/Stirling%27s_approximation
[4] https://en.wikipedia.org/wiki/Gamma_function
[5]
https://en.wikipedia.org/wiki/Binomial_coefficient#Binomial_coefficient_in_programming_languages



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] hid 64bit binary for OS X (after upgrade to Catalina)?

[Albert Rafetseder]

> why not upload it to deken?

I'm just a noob and don't want to break things on other people's
computers :-)

More seriously: I didn't anticipate there could be more interest in
that, so I didn't bother even reading any docs on getting things
uploaded to deken yet.

Thanks for the push though, I'll consider the idea!

Albert.

> On 15.05.2020 18:08, Albert Rafetseder wrote:
>> Hi Peter,
>>
>>> after an OS X upgrade to Catalina my current 32bit binary of [hid]
>>> does not
>>> work anymore due to Apple dropping support for 32bit.
>>>
>>> Does anyone have a 64bit binary at hand? Is there any other workaround?
>> I can send you (off-list) a binary from my build:
>>
>> https://gitlab.com/albert/pd-hid
>> https://lists.puredata.info/pipermail/pd-dev/2020-04/022366.html
>>
>> Best,
>>    Albert.
>>
>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
> 
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] hid 64bit binary for OS X (after upgrade to Catalina)?

[Albert Rafetseder]

Hi Peter,

> after an OS X upgrade to Catalina my current 32bit binary of [hid] does not
> work anymore due to Apple dropping support for 32bit. 
> 
> Does anyone have a 64bit binary at hand? Is there any other workaround?

I can send you (off-list) a binary from my build:

https://gitlab.com/albert/pd-hid
https://lists.puredata.info/pipermail/pd-dev/2020-04/022366.html

Best,
  Albert.



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] font issues/questions, and also discrepancies between operating systems

[Albert Rafetseder]

Hi Matt,

> is there a way to get osx to remember font settings?  It used to work
> automatically, but now it doesn't.

A half-solution: There's an input box labeled "Startup flags" under Wish
-> Preferences -> Startup..., and you may set

-font-size 16

(or whatever suits you) there. Unfortunately, though expectedly, this
only affects patches created anew. When I open an existing patch or help
file, it is still rendered using the default small font. The same goes
for the main Pd window.

More similar font tips:
https://github.com/pure-data/pure-data/tree/master/font

More startup flags: pd -help

More on startup settings via the GUI:
https://puredata.info/docs/faq/pdsettings

Cheers,
  Albert.



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list