Re: [PD] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[Dan Wilcox]

One option is to directly circumvent the app/binary quarantine process.
Essentially, you can remove the quarantine flag manually:

sudo xattr -r -d com.apple.quarantine path/to/MyApp.app

Print the current flags to check with:

xattr path/to/MyApp.app

I think this should work with dylibs as well.

The externals could be shipped with an additional script for macOS which
users can run once to remove the compiled externals from quarantine. There
should be no more popups after.

This does, however, open up possible attack vectors, but anything more than
what we already had before. I think it is a reasonable approach to ask
users to decide to run the script themselves, although there will be added
friction.

On Wed, Oct 12, 2022 at 2:04 AM Alexandre Torres Porres 
wrote:

> I'm still on old macs and I am not yet sure if my stuff is working or not
> in new macs. I just updated ELSE btw, I am now wondering if people can use
> it just fine or if it doesn't work or is a nightmare (like asking every
> time if on external should be loaded).
>
> Em ter., 11 de out. de 2022 às 15:03, Dan Wilcox 
> escreveu:
>
>> You already have you answer: no code signing or notarization means users
>> get the security popup when the dylibs are loaded but they just have to
>> select open as far as I know. Gatekeeper asks them once, then the system
>> remembers the selection. I believe it may also require changing a privacy
>> setting in System Preferences to allow it.
>>
>> I already added the "Disable library validation" entitlement back for the
>> first Pd release for 10.15 which introduced the stronger security settings.
>>
>> Also, I think calling them "thieves" is misleading. If you don't want to
>> use the platform or the services which are provided with the developer
>> account, don't. No one is forcing you. Please don't contribute to FUD.
>>
>> You could simply provide the code and perhaps the make files to automate
>> the process, then convince an institution to pay for the developer account
>> license. I included this as one of my expenses for my last funded iOS
>> project... :)
>>
>> On Oct 11, 2022, at 7:12 PM, Lucas Cordiviola 
>> wrote:
>>
>> @ Dan
>>
>> Thanks for sharing this. I'll be digging about  ` you need an Apple
>> Developer account (and Apple ID to sign up for one)`. If there's no
>> workaround about the us$100 i'll be giving up notarizing builds. Do you
>> know of a way to not send money to the thieves (if i'm not mistaken) ?
>>
>> or to put it in another way:
>>
>> if I don't codesign/notarize the builds: is just that users have an "open
>> anyway" dialog? or is it a total "show stopper" that quits Pd?
>>
>> Which way should I go without the $100 ?
>>
>>
>> 
>> Dan Wilcox
>> @danomatika 
>> danomatika.com
>> robotcowboy.com
>>
>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
>>
>

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

Re: [PD] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[Alexandre Torres Porres]

I'm still on old macs and I am not yet sure if my stuff is working or not
in new macs. I just updated ELSE btw, I am now wondering if people can use
it just fine or if it doesn't work or is a nightmare (like asking every
time if on external should be loaded).

Em ter., 11 de out. de 2022 às 15:03, Dan Wilcox 
escreveu:

> You already have you answer: no code signing or notarization means users
> get the security popup when the dylibs are loaded but they just have to
> select open as far as I know. Gatekeeper asks them once, then the system
> remembers the selection. I believe it may also require changing a privacy
> setting in System Preferences to allow it.
>
> I already added the "Disable library validation" entitlement back for the
> first Pd release for 10.15 which introduced the stronger security settings.
>
> Also, I think calling them "thieves" is misleading. If you don't want to
> use the platform or the services which are provided with the developer
> account, don't. No one is forcing you. Please don't contribute to FUD.
>
> You could simply provide the code and perhaps the make files to automate
> the process, then convince an institution to pay for the developer account
> license. I included this as one of my expenses for my last funded iOS
> project... :)
>
> On Oct 11, 2022, at 7:12 PM, Lucas Cordiviola 
> wrote:
>
> @ Dan
>
> Thanks for sharing this. I'll be digging about  ` you need an Apple
> Developer account (and Apple ID to sign up for one)`. If there's no
> workaround about the us$100 i'll be giving up notarizing builds. Do you
> know of a way to not send money to the thieves (if i'm not mistaken) ?
>
> or to put it in another way:
>
> if I don't codesign/notarize the builds: is just that users have an "open
> anyway" dialog? or is it a total "show stopper" that quits Pd?
>
> Which way should I go without the $100 ?
>
>
> 
> Dan Wilcox
> @danomatika 
> danomatika.com
> robotcowboy.com
>
>
>
> ___
> 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] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[hans w. koch]

looks like you can „ask apple“ only if you are  "members of the Apple Developer 
Program or Apple Developer Enterprise Program“
furthermore topics are set to apples latest + shiniest
https://developer.apple.com/events/ask-apple/questions-and-answers/ 


your proposed question is great: I would like to know how an open source 
project which relies on freely-shared plugins is supposed to exist on a 
platform that is making it harder on accessibility.
just apple doesn´t seem to provide a slot to ask it - they might have their 
reasons…

i could try to wrestle my institution into paying for a dev account, which i 
could open up to people like lucas.
another possibility would be a donated dev account - 100$ per year is like 2 
beers per month. drink less, have more code :-) 
would that even be allowed by apple?

best
hans

> Am 11.10.2022 um 23:37 schrieb Dan Wilcox :
> 
> Looks like we could “Ask Apple”…
> 
> https://developer.apple.com/events/ask-apple/ 
> 
> 
> I would like to know how an open source project which relies on freely-shared 
> plugins is supposed to exist on a platform that is making it harder on 
> accessibility.
> 
> I have had a developer account for many years but that doesn’t mean I like 
> jumping through these hoops after spending too long figuring them out. It 
> would be nicer if you, as a user, could simply tell the system: “Pd can load 
> whatever dynamic libs.”
> 
> It’s the same situation for other environments such as Max.
> 
> enohp ym morf tnes
> ---
> Dan Wilcox
> danomatika.com
> robotcowboy.com
> 
> 
>> On Oct 11, 2022, at 8:01 PM, Dan Wilcox  wrote:
>> 
>> You already have you answer: no code signing or notarization means users 
>> get the security popup when the dylibs are loaded but they just have to 
>> select open as far as I know. Gatekeeper asks them once, then the system 
>> remembers the selection. I believe it may also require changing a privacy 
>> setting in System Preferences to allow it.
>> 
>> I already added the "Disable library validation" entitlement back for the 
>> first Pd release for 10.15 which introduced the stronger security settings.
>> 
>> Also, I think calling them "thieves" is misleading. If you don't want to use 
>> the platform or the services which are provided with the developer account, 
>> don't. No one is forcing you. Please don't contribute to FUD.
>> 
>> You could simply provide the code and perhaps the make files to automate the 
>> process, then convince an institution to pay for the developer account 
>> license. I included this as one of my expenses for my last funded iOS 
>> project... :)
>> 
>>> On Oct 11, 2022, at 7:12 PM, Lucas Cordiviola >> > wrote:
>>> 
>>> @ Dan
>>> 
>>> Thanks for sharing this. I'll be digging about  ` you need an Apple 
>>> Developer account (and Apple ID to sign up for one)`. If there's no 
>>> workaround about the us$100 i'll be giving up notarizing builds. Do you 
>>> know of a way to not send money to the thieves (if i'm not mistaken) ?
>>> 
>>> or to put it in another way:
>>> 
>>> if I don't codesign/notarize the builds: is just that users have an "open 
>>> anyway" dialog? or is it a total "show stopper" that quits Pd?
>>> 
>>> Which way should I go without the $100 ?
>> 
>> 
>> Dan Wilcox
>> @danomatika 
>> danomatika.com 
>> robotcowboy.com 
>> 
>> 
>> 
> ___
> 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] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[Dan Wilcox]

Looks like we could “Ask Apple”…

https://developer.apple.com/events/ask-apple/

I would like to know how an open source project which relies on freely-shared 
plugins is supposed to exist on a platform that is making it harder on 
accessibility.

I have had a developer account for many years but that doesn’t mean I like 
jumping through these hoops after spending too long figuring them out. It would 
be nicer if you, as a user, could simply tell the system: “Pd can load whatever 
dynamic libs.”

It’s the same situation for other environments such as Max.

enohp ym morf tnes
---
Dan Wilcox
danomatika.com
robotcowboy.com


> On Oct 11, 2022, at 8:01 PM, Dan Wilcox  wrote:
> 
> You already have you answer: no code signing or notarization means users get 
> the security popup when the dylibs are loaded but they just have to select 
> open as far as I know. Gatekeeper asks them once, then the system remembers 
> the selection. I believe it may also require changing a privacy setting in 
> System Preferences to allow it.
> 
> I already added the "Disable library validation" entitlement back for the 
> first Pd release for 10.15 which introduced the stronger security settings.
> 
> Also, I think calling them "thieves" is misleading. If you don't want to use 
> the platform or the services which are provided with the developer account, 
> don't. No one is forcing you. Please don't contribute to FUD.
> 
> You could simply provide the code and perhaps the make files to automate the 
> process, then convince an institution to pay for the developer account 
> license. I included this as one of my expenses for my last funded iOS 
> project... :)
> 
>> On Oct 11, 2022, at 7:12 PM, Lucas Cordiviola  wrote:
>> 
>> @ Dan
>> 
>> Thanks for sharing this. I'll be digging about  ` you need an Apple 
>> Developer account (and Apple ID to sign up for one)`. If there's no 
>> workaround about the us$100 i'll be giving up notarizing builds. Do you know 
>> of a way to not send money to the thieves (if i'm not mistaken) ?
>> 
>> or to put it in another way:
>> 
>> if I don't codesign/notarize the builds: is just that users have an "open 
>> anyway" dialog? or is it a total "show stopper" that quits Pd?
>> 
>> Which way should I go without the $100 ?
> 
> 
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
> 
> 
> 
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[Dan Wilcox]

You already have you answer: no code signing or notarization means users get 
the security popup when the dylibs are loaded but they just have to select open 
as far as I know. Gatekeeper asks them once, then the system remembers the 
selection. I believe it may also require changing a privacy setting in System 
Preferences to allow it.

I already added the "Disable library validation" entitlement back for the first 
Pd release for 10.15 which introduced the stronger security settings.

Also, I think calling them "thieves" is misleading. If you don't want to use 
the platform or the services which are provided with the developer account, 
don't. No one is forcing you. Please don't contribute to FUD.

You could simply provide the code and perhaps the make files to automate the 
process, then convince an institution to pay for the developer account license. 
I included this as one of my expenses for my last funded iOS project... :)

> On Oct 11, 2022, at 7:12 PM, Lucas Cordiviola  wrote:
> 
> @ Dan
> 
> Thanks for sharing this. I'll be digging about  ` you need an Apple Developer 
> account (and Apple ID to sign up for one)`. If there's no workaround about 
> the us$100 i'll be giving up notarizing builds. Do you know of a way to not 
> send money to the thieves (if i'm not mistaken) ?
> 
> or to put it in another way:
> 
> if I don't codesign/notarize the builds: is just that users have an "open 
> anyway" dialog? or is it a total "show stopper" that quits Pd?
> 
> Which way should I go without the $100 ?


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



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

Re: [PD] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[hans w. koch]

hi lucas,

> if I don't codesign/notarize the builds: is just that users have an "open 
> anyway" dialog? or is it a total "show stopper" that quits Pd?
its a bit more than just that (sigh), but not a complete show stopper.

i fully symphatize with your take on that, even if it means i will have to hop 
thru the (firey) loops, apple is setting up to letting me allow running your 
code on my machine.

for us as a community we should probably start thinking how we can pool 
ressources, so that developers who don´t have / don´t want an apple dev account 
etc. can still provide their work to the community.
if i understood correctly, apples firewall around its ecosystem will be getting 
even harder to overcome with the next system (ventura) and who knows, whats in 
the pipeline after that.

my 2 (unhelpful) cents

hans

> Am 11.10.2022 um 19:12 schrieb Lucas Cordiviola :
> 
> @ Dan
> 
> Thanks for sharing this. I'll be digging about  ` you need an Apple Developer 
> account (and Apple ID to sign up for one)`. If there's no workaround about 
> the us$100 i'll be giving up notarizing builds. Do you know of a way to not 
> send money to the thieves (if i'm not mistaken) ?
> 
> or to put it in another way:
> 
> if I don't codesign/notarize the builds: is just that users have an "open 
> anyway" dialog? or is it a total "show stopper" that quits Pd?
> 
> Which way should I go without the $100 ?
> 
> 
> --
> 
> Mensaje telepatico asistido por maquinas.
> 
> On 11/10/2022 12:55, Dan Wilcox wrote:
>> Howdy Lucas,
>> 
>> I have the makefiles working but realize now I need to do some refactoring 
>> to better handle non-app bundles like dylib libraries. Apparently the 
>> notarization process is a little different. In any case, you can check them 
>> out for now but I will be working on them further:
>> 
>> https://github.com/zkmkarlsruhe/mac-app-builder
>> 
>> Yes, you need an Apple Developer account (and Apple ID to sign up for one) 
>> in order to create the certificates for code signing as well as 
>> notarization. The overview is in the readme.
>> 
>> The notarization process for dylibs appears to be:
>> 
>> * build the dylibs (in our case pd externals)
>> * codesign them
>> * notarize them (upload to Apple notarization server)
>> * package them into a disk image .dmg
>> * sign the dmg
>> * staple the dmg with the notarization ticket
>> 
>> Distributing via zip will not work in this case because the zip cannot be 
>> signed like a dmg.
>> 
>> I think it might make sense for us to make a Makefile.pdlibnotarizer or 
>> something similar.
>> 
>> I also have a separate repo with example programs (Cocoa, openFrameworks, 
>> console + dylib) for testing, but it's not ready yet. I managed to get the 
>> dylib signed this morning which is when I found out my assumptions for the 
>> whole process are different between apps and libs. :(
>> 
>>> On Oct 11, 2022, at 4:48 PM, Lucas Cordiviola  wrote:
>>> 
>>> @ Dan
>>> 
>>> I'm back on my "machines home". I did:
>>> 
>>> xcrun notarytool
>>> 
>>> and I got its help options.
>>> 
>>> Do I need an `apple developer` account ?
>>> 
>>> I don't even have an `apple id`.
>>> 
>>> How should I proceed? do I wait for your script? do i get my `apple id`?
>>> 
>>> I'm sure I'm not the only one willing to provide arm64 builds (pd-porres 
>>> has already inquired me on this).
>> 
>> 
>> Dan Wilcox
>> @danomatika >
>> danomatika.com  > >
>> robotcowboy.com  > >
>> 
>> 
>> 
> 
> 
> 
> ___
> 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] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[Lucas Cordiviola]

@ Dan

Thanks for sharing this. I'll be digging about  ` you need an Apple 
Developer account (and Apple ID to sign up for one)`. If there's no 
workaround about the us$100 i'll be giving up notarizing builds. Do you 
know of a way to not send money to the thieves (if i'm not mistaken) ?


or to put it in another way:

if I don't codesign/notarize the builds: is just that users have an 
"open anyway" dialog? or is it a total "show stopper" that quits Pd?


Which way should I go without the $100 ?


--

Mensaje telepatico asistido por maquinas.

On 11/10/2022 12:55, Dan Wilcox wrote:

Howdy Lucas,

I have the makefiles working but realize now I need to do some 
refactoring to better handle non-app bundles like dylib libraries. 
Apparently the notarization process is a little different. In any 
case, you can check them out for now but I will be working on them 
further:


https://github.com/zkmkarlsruhe/mac-app-builder

Yes, you need an Apple Developer account (and Apple ID to sign up for 
one) in order to create the certificates for code signing as well as 
notarization. The overview is in the readme.


The notarization process for dylibs appears to be:

* build the dylibs (in our case pd externals)
* codesign them
* notarize them (upload to Apple notarization server)
* package them into a disk image .dmg
* sign the dmg
* staple the dmg with the notarization ticket

Distributing via zip will not work in this case because the zip cannot 
be signed like a dmg.


I think it might make sense for us to make a Makefile.pdlibnotarizer 
or something similar.


I also have a separate repo with example programs (Cocoa, 
openFrameworks, console + dylib) for testing, but it's not ready yet. 
I managed to get the dylib signed this morning which is when I found 
out my assumptions for the whole process are different between apps 
and libs. :(


On Oct 11, 2022, at 4:48 PM, Lucas Cordiviola  
wrote:


@ Dan

I'm back on my "machines home". I did:

    xcrun notarytool

and I got its help options.

Do I need an `apple developer` account ?

I don't even have an `apple id`.

How should I proceed? do I wait for your script? do i get my `apple id`?

I'm sure I'm not the only one willing to provide arm64 builds 
(pd-porres has already inquired me on this).



Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 







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

Re: [PD] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[IOhannes m zmölnig]

Am 11. Oktober 2022 16:48:42 MESZ schrieb Lucas Cordiviola 
:
>
>
>Do I need an `apple developer` account ?

Yes.
100.00$ iirc.



mfg.sfg.jfd
IOhannes


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

Re: [PD] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[Dan Wilcox]

Howdy Lucas,

I have the makefiles working but realize now I need to do some refactoring to 
better handle non-app bundles like dylib libraries. Apparently the notarization 
process is a little different. In any case, you can check them out for now but 
I will be working on them further:

https://github.com/zkmkarlsruhe/mac-app-builder 


Yes, you need an Apple Developer account (and Apple ID to sign up for one) in 
order to create the certificates for code signing as well as notarization. The 
overview is in the readme.

The notarization process for dylibs appears to be:

* build the dylibs (in our case pd externals)
* codesign them
* notarize them (upload to Apple notarization server)
* package them into a disk image .dmg
* sign the dmg
* staple the dmg with the notarization ticket

Distributing via zip will not work in this case because the zip cannot be 
signed like a dmg.

I think it might make sense for us to make a Makefile.pdlibnotarizer or 
something similar.

I also have a separate repo with example programs (Cocoa, openFrameworks, 
console + dylib) for testing, but it's not ready yet. I managed to get the 
dylib signed this morning which is when I found out my assumptions for the 
whole process are different between apps and libs. :(

> On Oct 11, 2022, at 4:48 PM, Lucas Cordiviola  wrote:
> 
> @ Dan
> 
> I'm back on my "machines home". I did:
> 
> xcrun notarytool
> 
> and I got its help options.
> 
> Do I need an `apple developer` account ?
> 
> I don't even have an `apple id`.
> 
> How should I proceed? do I wait for your script? do i get my `apple id`?
> 
> I'm sure I'm not the only one willing to provide arm64 builds (pd-porres has 
> already inquired me on this).


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



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

Re: [PD] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[Lucas Cordiviola]

@ Dan

I'm back on my "machines home". I did:

    xcrun notarytool

and I got its help options.

Do I need an `apple developer` account ?

I don't even have an `apple id`.

How should I proceed? do I wait for your script? do i get my `apple id`?

I'm sure I'm not the only one willing to provide arm64 builds (pd-porres 
has already inquired me on this).




--

Mensaje telepatico asistido por maquinas.

On 08/10/2022 10:46, Lucas Cordiviola wrote:

I meant "server room" as "machine room" or more accurate "home".

I actually have an Monterey VM via qemu on Debian11 (on some amd-A6 
cpu). I tried `xcrun --find altool` and it returned `not found`.


I got xcode via `xcode-select --install`.


--

Mensaje telepatico asistido por maquinas.

On 10/8/2022 10:34 AM, Dan Wilcox wrote:
I'd suggest the latest versions of Big Sur, so 11.7. My work laptop 
is on 12 which is also fine. macOS 13 Ventura comes out soon, but 
it's too soon to set up a build environment for it, at least on a 
server.


On Oct 8, 2022, at 3:16 PM, Lucas Cordiviola  
wrote:


Actually using altool is deprecated and you get a warning that the 
uploads will fail after a certain date. Xcode 13+ uses notarytool 
and will be the only way to submit for notarization in the (near) 
future. You will need a VM running macOS 11.3 at a minimum to 
install Xcode 13.



I'll try to get a 11.3 VM. I'm away from the "server room" for a 
couple of days.



Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 







___
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] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[Lucas Cordiviola]

I meant "server room" as "machine room" or more accurate "home".

I actually have an Monterey VM via qemu on Debian11 (on some amd-A6 
cpu). I tried `xcrun --find altool` and it returned `not found`.


I got xcode via `xcode-select --install`.


--

Mensaje telepatico asistido por maquinas.

On 10/8/2022 10:34 AM, Dan Wilcox wrote:
I'd suggest the latest versions of Big Sur, so 11.7. My work laptop is 
on 12 which is also fine. macOS 13 Ventura comes out soon, but it's 
too soon to set up a build environment for it, at least on a server.


On Oct 8, 2022, at 3:16 PM, Lucas Cordiviola  
wrote:


Actually using altool is deprecated and you get a warning that the 
uploads will fail after a certain date. Xcode 13+ uses notarytool 
and will be the only way to submit for notarization in the (near) 
future. You will need a VM running macOS 11.3 at a minimum to 
install Xcode 13.



I'll try to get a 11.3 VM. I'm away from the "server room" for a 
couple of days.



Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 







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

Re: [PD] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[Dan Wilcox]

I'd suggest the latest versions of Big Sur, so 11.7. My work laptop is on 12 
which is also fine. macOS 13 Ventura comes out soon, but it's too soon to set 
up a build environment for it, at least on a server.

> On Oct 8, 2022, at 3:16 PM, Lucas Cordiviola  wrote:
> 
>> Actually using altool is deprecated and you get a warning that the uploads 
>> will fail after a certain date. Xcode 13+ uses notarytool and will be the 
>> only way to submit for notarization in the (near) future. You will need a VM 
>> running macOS 11.3 at a minimum to install Xcode 13.
> 
> 
> I'll try to get a 11.3 VM. I'm away from the "server room" for a couple of 
> days.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



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

Re: [PD] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[Lucas Cordiviola]

Actually using altool is deprecated and you get a warning that the 
uploads will fail after a certain date. Xcode 13+ uses notarytool and 
will be the only way to submit for notarization in the (near) future. 
You will need a VM running macOS 11.3 at a minimum to install Xcode 13.



I'll try to get a 11.3 VM. I'm away from the "server room" for a couple 
of days.


So far I have both methods implemented but just need to clean 
everything up before I am confident with sharing. This weekend, 
hopefully.\, as I have other stuff waiting.



No rush from my side. I think also others will benefit from the script. 
I'm also planing to Dekenize other of my old externals for mac arm64.


OTOH it's still fine for users to build simpler binaries themselves. 
No warnings when used on the same build system.



Yes. foo(sources).dek should be encouraged.



--

Mensaje telepatico asistido por maquinas.

On 10/7/2022 8:17 PM, Dan Wilcox wrote:




On Oct 7, 2022, at 12:00 PM, pd-list-requ...@lists.iem.at wrote:

Message: 1
Date: Thu, 6 Oct 2022 17:32:50 -0300
From: Lucas Cordiviola 
To: "hans w. koch" 
Cc: William Brent , Pd-List

Subject: Re: [PD] [hidraw] pre Deken release. was:(Reading/writing a
HID device current best practice?)
Message-ID:


Content-Type: text/plain; charset=UTF-8; format=flowed

Thanks Hans!

I thank all the M1 testers.

Seems I'll wait for Dan's makefile for the notarizing stuff. Or later
try to update if possible my Xcode VM (as in iem-ci.yml) to be able to :
"try to switch to the latest and greatest XCode, so we get 'altool'" and
stuff.


Actually using altool is deprecated and you get a warning that the 
uploads will fail after a certain date. Xcode 13+ uses notarytool and 
will be the only way to submit for notarization in the (near) future. 
You will need a VM running macOS 11.3 at a minimum to install Xcode 13.


So far I have both methods implemented but just need to clean 
everything up before I am confident with sharing. This weekend, 
hopefully.\, as I have other stuff waiting.



M1 users please note that is not that simple (for me or you) to (build
and) share arm64 binaries.


OTOH it's still fine for users to build simpler binaries themselves. 
No warnings when used on the same build system.



Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com>
robotcowboy.com <http://robotcowboy.com>







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

Re: [PD] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[Dan Wilcox]

> On Oct 7, 2022, at 12:00 PM, pd-list-requ...@lists.iem.at wrote:
> 
> Message: 1
> Date: Thu, 6 Oct 2022 17:32:50 -0300
> From: Lucas Cordiviola mailto:lucard...@hotmail.com>>
> To: "hans w. koch" mailto:hansw.k...@gmail.com>>
> Cc: William Brent mailto:william.br...@gmail.com>>, 
> Pd-List
>   mailto:pd-list@lists.iem.at>>
> Subject: Re: [PD] [hidraw] pre Deken release. was:(Reading/writing a
>   HID device current best practice?)
> Message-ID:
>   
>   
> <mailto:ds7pr10mb484547c68358a0f38020d324a6...@ds7pr10mb4845.namprd10.prod.outlook.com>>
>   
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> Thanks Hans!
> 
> I thank all the M1 testers.
> 
> Seems I'll wait for Dan's makefile for the notarizing stuff. Or later 
> try to update if possible my Xcode VM (as in iem-ci.yml) to be able to : 
> "try to switch to the latest and greatest XCode, so we get 'altool'" and 
> stuff.

Actually using altool is deprecated and you get a warning that the uploads will 
fail after a certain date. Xcode 13+ uses notarytool and will be the only way 
to submit for notarization in the (near) future. You will need a VM running 
macOS 11.3 at a minimum to install Xcode 13.

So far I have both methods implemented but just need to clean everything up 
before I am confident with sharing. This weekend, hopefully.\, as I have other 
stuff waiting.

> M1 users please note that is not that simple (for me or you) to (build 
> and) share arm64 binaries.

OTOH it's still fine for users to build simpler binaries themselves. No 
warnings when used on the same build system.


Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



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

Re: [PD] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[Lucas Cordiviola]

Thanks Hans!

I thank all the M1 testers.

Seems I'll wait for Dan's makefile for the notarizing stuff. Or later 
try to update if possible my Xcode VM (as in iem-ci.yml) to be able to : 
"try to switch to the latest and greatest XCode, so we get 'altool'" and 
stuff.


M1 users please note that is not that simple (for me or you) to (build 
and) share arm64 binaries.


The worst case scenario I see from the tests is that you'll have to go 
ahead with "malicious software" warning or I simply build with an older 
VM and for intel x86_64.


Thanks again for all the testers.


--

Mensaje telepatico asistido por maquinas.

On 06/10/2022 16:06, hans w. koch wrote:

hi lucas,

i just tested on mac os monterey / M1 and i still had to allow the 
same way as william.
then it worked fine (only had an external mouse to test - not very 
thrilling…)


thanks for the effort!

hans




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

Re: [PD] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[hans w. koch]

hi lucas,

i just tested on mac os monterey / M1 and i still had to allow the same way as 
william.
then it worked fine (only had an external mouse to test - not very thrilling…)

thanks for the effort!

hans

> Am 06.10.2022 um 16:41 schrieb Lucas Cordiviola :
> 
> Hi William,
> 
> Thanks for the test. I did an ad-hoc codesign but seems it is not enough. Now 
> I signed with a self certificate:
> 
> https://nc.nubegris.com.ar/index.php/s/KL3dF777TPwTkM9 
> 
> 
> I'm not sure if your mac can test this one as you already got the file in 
> your white list.
> 
> If you know a way to not get false positives tests are welcomed.
> 
> (also for anyone else reading with an arm64 macOS).
> 
> 
> --
> 
> Mensaje telepatico asistido por maquinas.
> 
> On 06/10/2022 10:28, William Brent wrote:
>> Hi Lucas - thanks for this! I just tested it on an M1 MacBook Pro under 
>> macOS Monterey. I got the "malicious software" warning and had to go to 
>> system prefs/security & privacy to allow the external to be run anyway, but 
>> then it worked just fine to access my Logitech game controller.
>> 
>> On Wed, Oct 5, 2022 at 7:00 AM Lucas Cordiviola  
>> wrote:
>> 
>>Hi all,
>> 
>>Next week or so i'll hopefully release hidraw. An object that
>>reads raw
>>bytes from HIDs.
>> 
>>Can anyone test this builds on a mac M1 with arm64 or a Monterey
>>x64 intel?
>> 
>>https://nc.nubegris.com.ar/index.php/s/Rk7HRq67eCqF7kQ
>> 
>>i'm not sure if i did correctly the code sign. (the object seems
>>to work
>>on my monterey VM).
>> 
>>If anyone (not on macOS) is willing to test the above link also has
>>Linux and Windows binaries.
>> 
>>feedback is welcomed.
>> 
>> 
>>--
>> 
>>-- Mensaje telepatico asistido por maquinas.
>> 
>> 
>> 
>> 
>>___
>>Pd-list@lists.iem.at mailing list
>>UNSUBSCRIBE and account-management ->
>>https://lists.puredata.info/listinfo/pd-list
>> 
>> 
>> 
>> -- 
>> William Brent
>> 
>> “Great minds flock together”
>> Conflations: conversational idiom for the 21st century
>> 
>> www.conflations.com  
>> >
> 
> 
> 
> ___
> 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] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[Lucas Cordiviola]

Hi Sebastian,

Thanks for the test.

Would hidraw enable to get access multitouch data? Like fingerpincher 
on Max?



I doubt it but not sure. Looking at the sources of fingerincher from 
https://www.anyma.ch/2009/research/multitouch-external-for-maxmsp/ this 
looks to me as an apple exclusive device and software. I guess that 
someone with a an apple machine can port fingerpincher to Pd exclusively 
for macOS.


But what happens if you move two or more fingers in the touchpad? (you 
can get all the list of bytes in the listbox)


and afraid of saying something stupid: what happens if you create 4 
[hidraw] objects and open devices 4, 5, 6 and 7 (one per object). Do you 
get at least 4 different readings?




--

Mensaje telepatico asistido por maquinas.

On 06/10/2022 11:05, Sebastian Lexer wrote:
Amazing, I could only test running it on the M1 itself without any 
additional equipment, but all seems to work as expected.


After going through the 'malicious software stuff' I'm getting data 
results for devices 4-7. Ech of these report xy coordinate changes on 
the touchpad. Roughly >250 for right or up movements and <5 for left 
and down.


Would hidraw enable to get access multitouch data? Like fingerpincher 
on Max?


All best,
Sebastian




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

Re: [PD] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[IOhannes m zmoelnig]

On 10/6/22 17:14, Lucas Cordiviola wrote:

That would be fantastic. Please let me know when its done.


and then there is 
 
which is what I use on our CI-infrastructure to codesign Pd-externals.


it's not a ready-to-use script, as it is wrapped in a YAML-file, but 
hopefully you get the idea.


fgmdasr
IOhannes


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

Re: [PD] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[Lucas Cordiviola]

That would be fantastic. Please let me know when its done.


--

Mensaje telepatico asistido por maquinas.

On 06/10/2022 11:50, Dan Wilcox wrote:
You also need to notarize binaries, not just codesign. I am actually 
working on a Makefile which automates mac-specific distribution stuff 
like this and I can send you a link once I have it finalized.




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

Re: [PD] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[Dan Wilcox]

You also need to notarize binaries, not just codesign. I am actually working on 
a Makefile which automates mac-specific distribution stuff like this and I can 
send you a link once I have it finalized.

> On Oct 6, 2022, at 4:42 PM, pd-list-requ...@lists.iem.at wrote:
> 
> Message: 4
> Date: Thu, 6 Oct 2022 11:41:43 -0300
> From: Lucas Cordiviola mailto:lucard...@hotmail.com>>
> To: William Brent mailto:william.br...@gmail.com>>
> Cc: Pd-List mailto:pd-list@lists.iem.at>>
> Subject: Re: [PD] [hidraw] pre Deken release. was:(Reading/writing a
>   HID device current best practice?)
> Message-ID:
>   
>   
> <mailto:ds7pr10mb484596a77fb235b559ce1d11a6...@ds7pr10mb4845.namprd10.prod.outlook.com>>
>   
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> Hi William,
> 
> Thanks for the test. I did an ad-hoc codesign but seems it is not 
> enough. Now I signed with a self certificate:
> 
> ??? https://nc.nubegris.com.ar/index.php/s/KL3dF777TPwTkM9 
> <https://nc.nubegris.com.ar/index.php/s/KL3dF777TPwTkM9>
> 
> I'm not sure if your mac can test this one as you already got the file 
> in your white list.
> 
> If you know a way to not get false positives tests are welcomed.
> 
> (also for anyone else reading with an arm64 macOS).


Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



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

Re: [PD] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[Lucas Cordiviola]

Hi William,

Thanks for the test. I did an ad-hoc codesign but seems it is not 
enough. Now I signed with a self certificate:


    https://nc.nubegris.com.ar/index.php/s/KL3dF777TPwTkM9

I'm not sure if your mac can test this one as you already got the file 
in your white list.


If you know a way to not get false positives tests are welcomed.

(also for anyone else reading with an arm64 macOS).


--

Mensaje telepatico asistido por maquinas.

On 06/10/2022 10:28, William Brent wrote:
Hi Lucas - thanks for this! I just tested it on an M1 MacBook Pro 
under macOS Monterey. I got the "malicious software" warning and had 
to go to system prefs/security & privacy to allow the external to be 
run anyway, but then it worked just fine to access my Logitech game 
controller.


On Wed, Oct 5, 2022 at 7:00 AM Lucas Cordiviola 
 wrote:


Hi all,

Next week or so i'll hopefully release hidraw. An object that
reads raw
bytes from HIDs.

Can anyone test this builds on a mac M1 with arm64 or a Monterey
x64 intel?

https://nc.nubegris.com.ar/index.php/s/Rk7HRq67eCqF7kQ

i'm not sure if i did correctly the code sign. (the object seems
to work
on my monterey VM).

If anyone (not on macOS) is willing to test the above link also has
Linux and Windows binaries.

feedback is welcomed.


--

-- 
Mensaje telepatico asistido por maquinas.





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



--
William Brent

“Great minds flock together”
Conflations: conversational idiom for the 21st century

www.conflations.com 




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

Re: [PD] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[Sebastian Lexer]

Amazing, I could only test running it on the M1 itself without any 
additional equipment, but all seems to work as expected.


After going through the 'malicious software stuff' I'm getting data 
results for devices 4-7. Ech of these report xy coordinate changes on 
the touchpad. Roughly >250 for right or up movements and <5 for left and 
down.


Would hidraw enable to get access multitouch data? Like fingerpincher on 
Max?


All best,
Sebastian

William Brent wrote on 06/10/2022 14:28:
Hi Lucas - thanks for this! I just tested it on an M1 MacBook Pro 
under macOS Monterey. I got the "malicious software" warning and had 
to go to system prefs/security & privacy to allow the external to be 
run anyway, but then it worked just fine to access my Logitech game 
controller.


On Wed, Oct 5, 2022 at 7:00 AM Lucas Cordiviola > wrote:


Hi all,

Next week or so i'll hopefully release hidraw. An object that
reads raw
bytes from HIDs.

Can anyone test this builds on a mac M1 with arm64 or a Monterey
x64 intel?

https://nc.nubegris.com.ar/index.php/s/Rk7HRq67eCqF7kQ

i'm not sure if i did correctly the code sign. (the object seems
to work
on my monterey VM).

If anyone (not on macOS) is willing to test the above link also has
Linux and Windows binaries.

feedback is welcomed.


--

-- 
Mensaje telepatico asistido por maquinas.





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



--
William Brent

“Great minds flock together”
Conflations: conversational idiom for the 21st century

www.conflations.com 


___
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] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[William Brent]

Hi Lucas - thanks for this! I just tested it on an M1 MacBook Pro under
macOS Monterey. I got the "malicious software" warning and had to go to
system prefs/security & privacy to allow the external to be run anyway, but
then it worked just fine to access my Logitech game controller.

On Wed, Oct 5, 2022 at 7:00 AM Lucas Cordiviola 
wrote:

> Hi all,
>
> Next week or so i'll hopefully release hidraw. An object that reads raw
> bytes from HIDs.
>
> Can anyone test this builds on a mac M1 with arm64 or a Monterey x64 intel?
>
>  https://nc.nubegris.com.ar/index.php/s/Rk7HRq67eCqF7kQ
>
> i'm not sure if i did correctly the code sign. (the object seems to work
> on my monterey VM).
>
> If anyone (not on macOS) is willing to test the above link also has
> Linux and Windows binaries.
>
> feedback is welcomed.
>
>
> --
>
> --
> Mensaje telepatico asistido por maquinas.
>
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>


-- 
William Brent

“Great minds flock together”
Conflations: conversational idiom for the 21st century

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

Re: [PD] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[Lucas Cordiviola]

Hi Simon,

Interesting! I am away from my M1 for quite a while, might be able to 
do some testing in a few weeks.



Thanks, i need this confirmation.


Will [hidraw] also support writing to the device? There are some 
devices that need 2 way communication to enable/disable functions and 
states.



Well from the wrapped hidapi (https://github.com/libusb/hidapi) that the 
object uses is totally easy to write to the device but i'm scared about 
it. They warm that writing (incorrect values i suppose) can brick the 
device.


I only have an cheap USB ps2 compatible joystick to test. I don't know 
yet how to start. In theory I can have a "write" method alla:


[write 1 0 255 255 127 0(
|
[hidraw]

but i'm unsure what to write.

Also I read in https://github.com/libusb/hidapi/issues/167 that certain 
things like making the joystick rumble is not possible directly via hidapi.


I'll have to dig more may be for version 0.2.0.

Any feature request, discussion or knowledge can continue on 
https://github.com/Lucarda/pd-hidraw


PS: as of v0.1.0 i'm totally happy that is so easy an cheap to hack an 
usb joystick an make an 12 foot-switch pedal. Or use the joystick as a 
modulation wheel, etc. :)


Mensaje telepatico asistido por maquinas.

On 06/10/2022 04:31, Simon Iten wrote:

Hi Luca,

Interesting! I am away from my M1 for quite a while, might be able to 
do some testing in a few weeks. Will [hidraw] also support writing to 
the device? There are some devices that need 2 way communication to 
enable/disable functions and states.


On Wed, 5 Oct 2022, 13:00 Lucas Cordiviola,  wrote:

Hi all,

Next week or so i'll hopefully release hidraw. An object that
reads raw
bytes from HIDs.

Can anyone test this builds on a mac M1 with arm64 or a Monterey
x64 intel?

https://nc.nubegris.com.ar/index.php/s/Rk7HRq67eCqF7kQ

i'm not sure if i did correctly the code sign. (the object seems
to work
on my monterey VM).

If anyone (not on macOS) is willing to test the above link also has
Linux and Windows binaries.

feedback is welcomed.


--

-- 
Mensaje telepatico asistido por maquinas.





___
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] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[Simon Iten]

Hi Luca,

Interesting! I am away from my M1 for quite a while, might be able to do
some testing in a few weeks. Will [hidraw] also support writing to the
device? There are some devices that need 2 way communication to
enable/disable functions and states.

On Wed, 5 Oct 2022, 13:00 Lucas Cordiviola,  wrote:

> Hi all,
>
> Next week or so i'll hopefully release hidraw. An object that reads raw
> bytes from HIDs.
>
> Can anyone test this builds on a mac M1 with arm64 or a Monterey x64 intel?
>
>  https://nc.nubegris.com.ar/index.php/s/Rk7HRq67eCqF7kQ
>
> i'm not sure if i did correctly the code sign. (the object seems to work
> on my monterey VM).
>
> If anyone (not on macOS) is willing to test the above link also has
> Linux and Windows binaries.
>
> feedback is welcomed.
>
>
> --
>
> --
> Mensaje telepatico asistido por maquinas.
>
>
>
>
> ___
> 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