Catalina release plan #7
Comments
|
One thing I was thinking about is reuse keys (I think that’s the terminology) for the virtual endpoints. This way you don’t end up opening additional endpoints with the same name accuse rally. I have run into that issue in some of my other applications, but I don’t remember if it’s a problem for MIDI Patchbay since it cleans the endpoints up on exit.
My use case reusing the same endpoint, named explicitly for the app, whenever the app starts and MIDI is enabled. If I didn’t set the reuse key, the system might end up with multiple, similarly named endpoints.
Again, probably not an issue with this app, as I recall, but if you are looking into endpoint refactoring anyway, could be good to double check.
enohp ym morf tnes
-----------
Dan Wilcox
danomatika.com
robotcowboy.com
… On Dec 11, 2019, at 7:05 AM, Pete Yandell ***@***.***> wrote:
@danomatika I've been thinking it over, and what I'd like to do is this:
Merge #6
Fix the display issues when editing virtual endpoints on Catalina
Disable dark mode for now, coz it only half works
Cherry pick your docs changes onto master
Add you and others to the credits and the README
Fix the build number
Release as 1.0.5 (just to differentiate it from your 1.0.4 release, in case anyone is confused)
Ideally I'll see if I can get it on the App Store, but I'm not sure how much work that'll be.
From there, I can do a 1.0.6 release with:
SecureCoding support
View-based tables for virtual endpoint editing
ARC changes
Any UI tweaks from your branch that seem like an obvious improvement
Maybe dark mode support (coz I don't think it'll be too hard)
That should give us a pretty solid, long-lasting release, with no deprecation warnings.
Sound sensible? Any details I've missed from your PRs that you think are important?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
MIDI Patchbay saves and loads the unique IDs for virtual endpoints in its files. See https://github.com/notahat/midi_patchbay/blob/master/PYMIDI/PYMIDIEndpoint.m#L82 and https://github.com/notahat/midi_patchbay/blob/master/PYMIDI/PYMIDIVirtualEndpoint.m#L33-L37 |
|
Ah perfect. No worries then. :) |
|
Update: I'm currently blocked by the icon! Apple won't validate an app without a 512x512@2x icon, and the current icon is much smaller. I'm hunting around for someone to help. |
|
Hah, funny enough.... I was considering offering to help with this. And I just wrapped on work for the next week and a half so I have some time to work on it. Would you want a new design, or basically just a highres rework of the current one? I'm game to take a stab at it. |
|
Alright here's something quick and dirty to at least get to validation. Can explore other options in the next week. https://www.dropbox.com/sh/9rhcmhti5em0jpp/AADlJulWyhO2fnmQ_feflqlEa?dl=0 |
|
Slightly modified/updated version. Icon file in dropbox link above. |
|
@carbon43 Thanks! I've definitely got some thoughts on the direction I'd like to go with it, but I'm also open to suggestions, coz I'm no designer. I'll see if I can scribble down some ideas tomorrow, to give you a bit more to go on. |
|
@notahat Hah, well my design days are mostly behind me. I'm a full time TD/DIT/V1 these days (among other hats worn) but for sure happy to help |
|
Just wanted to chime in and say I'm looking forward to this. Any progress? |
|
Hi just wanted to report that I managed to compile and run midi_patchbay with some issues on a Apple Mac mini M1 on apple silicon Big Sur 11.1 (Model: Macmini9,1, BootROM 6723.61.3, proc 8:4:4 processors, 16 GB) just fine. The basic MIDI patching functionality is working (great work!!), however the save dialog doesn't work yet. Link to compiled binary here: |
|
@jw-smaal Great to hear. Care to post a build zip link? :) |
|
The Link didn't work. |
|
The new build works for me on Big Sur. So nice to have MIDI Patchbay back! Thanks! |
|
@jw-smaal If you don't mind, I went ahead and added your build to the other test builds I made for "1.0.4": http://docs.danomatika.com/releases/midipatchbay/ |
From Firefox:
From Safari, it works. |
|
Just has a requirement to use MIDI Patchbay, but like jw-smaal, noticed that the save dialog doesn't work. The solution is to add "User Selected File" read/write access to the App Sandbox, which adds the following lines to entitlements: Then Save/Load functionality seems to work fine...suggest updating "MIDI Patchbay.entitlements" with these two lines; complies and runs well with this change. |
|
@axmonti I added the missing entitlement to a new universal 1.1.0 test2 build on http://docs.danomatika.com/releases/midipatchbay/ NOTE: None of these test builds are notarized, so Gatekeeper will throw up the "cannot be verified" dialog. Right-click on the .app and choose Open to bypass. |
|
Hi danomatika, Great - glad you applied the update; I also fixed the row highlighting this morning (I didn't see the issue in dark mode, but it became apparent in light mode). Just a few conditionals in PatchTableCell.m like so: I also had to change the Dictionary declaration to 'mutable' to enable updates to the key/value pair. Below is a text file of the changes; I think your 'alternate' repository is great, but please let me know if you'd like me to pull/merge the changes... |
|
If you make commits to your own fork, I can pull them into mine so they aggregate to the current PR or you can make your own.
enohp ym morf tnes
-----------
Dan Wilcox
danomatika.com
robotcowboy.com
… On Jul 15, 2021, at 6:28 PM, axmonti ***@***.***> wrote:
Hi danomatika,
Great - glad you applied the update; I also fixed the row highlighting this morning (I didn't see the issue in dark mode, but it became apparent in light mode). Just a few conditionals in PatchTableCell.m like so:
if (self.isHighlighted) {
[outputNameAttributes setValue:[NSColor alternateSelectedControlTextColor] forKey:NSForegroundColorAttributeName];
}
I also had to change the Dictionary declaration to 'mutable' to enable updates to the key/value pair. Below is a text file of the changes; I think your 'alternate' repository is great, but please let me know if you'd like me to pull/merge the changes...
PatchTableCell.txt
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
OK Dan, sounds good - updated PatchTableCell.m in my fork; please feel free to pull into your fork (and the current PR) |
|
Hi Dan, Ended up also resolving all deprecated code, enabling secure code, and re-enabling the Delete menu item. Realizing that Apple has some pretty strict app icon guidelines, I drew a new icon as well. I could see this making it to the App Store...let me know if you think anyone would be interested. Thanks,
|
|
Hey Andrew, Regarding the icon, Id done one myself a while back Im happy to contribute for any app store submission and update for the squircle life.... I applaud the one above, but I would say the wireframe of the Korg Nanopad would be potentially problematic from a C&D perspective. There's probably sufficient generic iconography that can be tapped into. I'll try and add mine to this thread when I get back to base in a few days, and maybe we can come up with something even better :) Edit: oh apparently its already in this thread above. |
|
Hi Marcus, Thanks for chiming in - feedback is far better than a dead thread (although it's interesting how this one is 'resurrected' every so often). As a longtime Apple dev, I know what you mean with maintaining an app in the store - I don't have any right now, and it's nice in one sense, but skills become dated far too quickly, so it's also nice to have something to stay 'connected' to the process/updates. I think having versions within and outside the App Store makes sense - this utility definitely addresses a need for a lightweight MIDI mapper. I downloaded your icon, which is really nice, but Apple guidelines say "no" to text in icons, so I couldn't see that one working outside of the generic MIDI outline, which does build nicely on the original icon. Nice call on the NanoKey, which I copied from the NanoKey2 beside my Mac! After the Apple vs. Samsung rounded rectangle phone debacle, I thought using the general shape would be ok (maybe even a nice nod to Korg). I can certainly remove the control pads on the left and make it "all keys", which would be more generic (without looking like a stereotypical keyboard). Definitely interested in your PoV. After creating the requisite umpteen icon and document sizes, I realized the MIDI cables become a bit unrecognizable in the dock (see the screenshot below); I'm thinking of just having one larger connector at the top with the keyboard at the bottom, which doesn't quite capture the "patch" aspect, but maybe it's ok?
|
|
Well Andrew, the funny thing about Apple HID and other guidelines is, they dont exactly do a good job following their own guidelines, not only with icons, but system and app UI paradigms. This has been the case for.... many years. Ive been making icons for myself and others since System 7, where I used to illustrate pixel by pixel, so I guess you can say I too am a longtime whatever something something.... In any case, there are plenty of third party apps within the iOS and MacOS app store ecosystems that have text in them, so I doubt that would lead to rejection. Ive learned to ignore their guidelines when it suites my tastes about as well as they ignore radars 😆 I think what I'd like to see personally is something that illustrates the idea of connection, especially given that there are already other midi related apps that play more directly off the midi connector itself. I may go back and rework mine without the text for those folks who dont want text, maybe with something like an abstract eurorack or general patchbay in the background.... not sure. Unfortunately the next few weeks are a bit busy so not sure when that'll happen but can add it in here once finished. Btw, highly recommend getting img2icon to save yourself time with icon versioning. |
|
Hi Marcus, Great - looking forward to your reworked version, and yes, no end of evidence that Apple is consistently inconsistent with following its own guidelines. I usually avoid text because it's more challenging for me to capture the "essence" of the application without words (plus it's a bit more international). I'm thinking the same way - something connection-related - a patchbay would be great. No rush obviously... nice to have a fellow "old-timer" here (don't like that term) - I think we're of the same 'vintage'; I started out of university programming the Motorola DSP56001 Digidesign card on System 7.
|
|
Sounds good, you'll probably also get a laugh out of this, which literally was posted a little bit ago: https://daringfireball.net/linked/2021/07/27/safari-15b4-toolbar-viticci |
|
We're a long way from the System 7 HID guidelines book! That's a bit crazy, I do like the Twitter response: "Good luck SE users". I did read something about the iOS 15 Safari debacle on Hacker News not too long ago, but I don't think it mentioned touch targets. A good example of Apple ignoring their own best practices for the sake of progress (I guess). Thanks for passing that along. |
@danomatika I've been thinking it over, and what I'd like to do is this:
Disable dark mode for now, coz it only half worksIt was easier just to get it working: Support dark mode #8Ideally I'll see if I can get it on the App Store, but I'm not sure how much work that'll be.
From there, I can do a 1.1.1 release with:
That should give us a pretty solid, long-lasting release, with no deprecation warnings.
Sound sensible? Any details I've missed from your PRs that you think are important?
The text was updated successfully, but these errors were encountered: