LAST CHANCE! Poly-Ana and L'il Poly-Ana 1.20 BETA w. OSX x64 AU support!

[Teksonik]

(The issue was having to almost completely re-write the user interface code to support x64 on OSX.)

I'm curious if it was worth it ? I mean has it generated enough sales of Mac versions to make it worth the effort?

Obviously as a Windows only user I'd prefer you'd spend that time on Win only versions but if Mac sales support you financially making it possible to spend more time coding then I'd have to concede it's worth the effort.......

Seems like I've seen a lot of Mac only issues and bug reports lately....not with PolyAna but just in general.... and sometimes wonder why any but the largest developers would bother with Mac support....

Anyway just wondering out loud....don't really expect an answer...........

[AdmiralQuality]

While I've thought a bit about charging more for the Mac version, I don't think that would fly.

One of the things we've lost with this new authorization system is knowing whether you're running OSX, Windows, or both. Before, when it was C/R, we could tell by the challenge codes. And it was mostly Mac by a significant margin. This discussion rapidly descends into things I can't talk freely about here, but yes, the Mac market matters and that's why I continually bust my ass to support them. And I've had good experiences using them in various recording settings, so I acknowledge that while most things are needlessly frustrating and/or expensive, they do make good music host platforms, and if at all possible, I want our software to run on them.

Hopefully this will be it for platform changes for a while, but I know they're brewing up the next way to force obsolescence on products and code which are currently working fine. And the cycle continues...

[ftech]

Not being a developer myself, I would underestimate by a ridiculous amount how much work is involved supporting both major OS's, but as a Mac owner, I for one appreciate the work ALL developers put into giving us great plugins to use.
I have no issue whatsoever with whichever copy protection a developer chooses to use...it is their plugin after all!
As for charging more for a Mac version....seeing as there is a minority of MS users out there who think all Mac owners are rich fools blinded by hype, yeah! Why not?!
Wouldn't it make more sense to charge more for the platform that wasn't selling as well????
There, that should upset some people

[AdmiralQuality]

The C++ code that describes the DSP process is exactly the same on both platforms. As is the high-level GUI code that lays out the interface and defines its behavior. But below that, the particular implementation of each GUI is completely different. The idea is you work that lower level layer out once, then never look at it again. (Of course, Apple keeps forcing us to look at it again.)

And that's exactly what's happening here. Something that was just a few lines of code in the Windows version -- the file open/save dialogs -- was ported to x64 on Windows with no modifications needed at all. But in Apple-land, it requires completely throwing away the old code (which previously worked fine in 32 bit and was roughly similar in size to the Windows implementation) and writing new code that also involves compilation of another language in a separate source file that we've had forced on us by Apple (Objective-C). The total amount of code is at least 20 times what it was before. And there are clearly a whole bunch of ways it can go subtly wrong -- no surprise given its needless complexity.

Anyway, that's what this Beta period is for. To get all this cross platform stuff ironed out yet again, and then I can proceed to not think about it anymore and get back to actually making new products and adding new functionality to the existing ones. That will be a very happy day here at the Admiralty!

[ftech]

Does the direct porting of the Windows code without modification impact on project size or performance? As in is the old code 'clean' enough without modification that it performs as economically as possible.
As i said, I'm not a developer, but it's very interesting reading what hurdles developers come up against and how they deal with them.
Seems like with Apples stipulations, and your need for more code to comply, we Mac users will get a much 'heavier' plugin for no real performance related reason.

To be on topic; As you already know, program and banks aren't loading...but I can SEE the banks whilst browsing.
This isn't stopping me using this marvellous synth, just making me all the more keen for when the extra banks and patches I have can be used once more!

[AdmiralQuality]

Does the direct porting of the Windows code without modification impact on project size or performance? As in is the old code 'clean' enough without modification that it performs as economically as possible.

Not quite sure I follow you there, but I'm pretty sure the answer is no. (Well, it affects the size of the *source code* for the project, as there's two sets of source for all the operating system dependent functions, i.e. all the GUI and file handling stuff.)

As far as "clean enough", the GUI doesn't affect the performance of the audio process in any significant way. (If it did you'd see CPU usage drop dramatically whenever you closed an editor window.)

Again, the code that actually makes and/or processes sound is exactly the same on both operating systems. Good C++ code is good C++ code, regardless. The process has no idea what OS it's running on. Indeed, these days both computers use the same kinds of CPUs so even the machine code that the C++ is compiled into is virtually identical between the platforms. It's just when you need to ask the operating system to "draw me a edit field here" or "create a file open dialog for me" that it gets different. And with these new changes they've forced on us for Cocoa (64 bit) compatibility, it's more different than ever!

Meanwhile in Windows-land, executable binaries from 1993 still run on the latest OS versions, ancient code still compiles as, while new libraries have been added, generally the older ones are not taken away. Porting our plug-ins to 64 bit in Windows literally took a few hours in one afternoon. On the Mac, it took man-years and here I am STILL working on it. (A good portion of that time is due to my not wanting to abandon code that had years of user testing behind it. But as it came down to having no choice, I finally bit the bullet and did it. Hence the need to go back to a Beta test again. Incredibly frustrating, as we'd been several years without a serious bug report. Poly-Ana was super-stable. And it will be again, after we get through this Beta period.)

As i said, I'm not a developer, but it's very interesting reading what hurdles developers come up against and how they deal with them.
Seems like with Apples stipulations, and your need for more code to comply, we Mac users will get a much 'heavier' plugin for no real performance related reason.

Again, not exactly sure what you mean by "heavier". Most of Poly-Ana is the graphics that make up the user interface. The actual binary executable is relatively small, as it contains no pre-canned sample data or stuff like that.

The Mac binaries are both 64 bit and 32 bit in one package. So that makes them a bit larger. But again, just because an executable is larger in file size, it doesn't necessarily mean it's slower. Only one code instruction is running on any one CPU core at any time. Extra instructions that aren't currently being called have no overhead, other than their disk and memory footprints, which again for a product like Poly-Ana are so small as to be negligible.

Actually, on taking a fresh look at the binaries, the OSX version of Poly-Ana.vst (19.5 MB) is nearly twice the size of the Windows version, Poly-Anax64.dll (10.6 MB). But that's not explained by the dual-binary on the Mac as again, most of the VST is the graphics. So yes, Mac executable code is just "fluffy" compared to Windows. (But of course Apple want it to be, they sell you the hard drives too!)

To be on topic; As you already know, program and banks aren't loading...but I can SEE the banks whilst browsing.
This isn't stopping me using this marvellous synth, just making me all the more keen for when the extra banks and patches I have can be used once more!

Let's try to narrow this down. To be clear, on Windows all of that is FINE. It's just the OSX program and bank file loading/saving dialog that is still giving us issues. (If we could get it to consistently deliver the right file name, it would load correctly.)

I'm working on that right now though so maybe I'll break through it. (If anybody would like to send me a working Cocoa implementation of open/save dialogs, I'd be happy to swallow some pride and "cheat" on this one. )

If you're using the VST version you could get someone on Windows to convert the banks to .fxb for you. I'd do it myself, but best that I stay on target here and hopefully get this fix out in the next few hours.

[AdmiralQuality]

Some progress!

So one of the issues has been, that the included Poly-Ana program (*.pap) and bank (*.pab) files, as well as the ones on our website ( http://www.admiralquality.com/products/ ... a/patches/ ), when unzipped onto a Mac, are coming up with the executable file attribute, preventing them from being selected as documents for load. They show up in Finder as type "Unix Executable File".

These .zips were made on Windows. But even when I zip these files on the Mac, starting with the correct file attributes, when unzipped they still come out as executables. So at this point in time I'm not sure if there's anything we can do at this end to fix these files for the Mac.

It's fairly easy to fix once the program and bank files are on your Mac, though. There's two ways. One is use "chmod -x [filename]" in a Terminal window to remove the executable attribute. Another is to change the file's extension to .txt, then back to .pab or .pap. Yes, I know this is completely stupid and annoying, but that's what we're going to have to do for now.

The other issue is the doubled file extensions on save, which is merely annoying but not a show-stopper. I'm going to spend another hour or so seeing if I can get that fixed or worked around, and if not, I'll go ahead and release Beta 4 with that as a known-issue.

Sound good?

[AdmiralQuality]

Beta 4 is up! http://www.admiralquality.com/products/Poly-Ana/ (The website hasn't been updated yet so it still says Beta 3, but the download links will actually serve you Beta 4.)

Changes, Poly-Ana 1.20 BETA 4 - 2014-10-05

- OSX: More fixes to program and bank file load/save dialogs, they should work in all cases now and the duplicate extensions have been fixed. Please note that sometimes our program (.pap) and bank (.pab) files are unzipping with the executable file attribute mistakenly set. This prevents them from being able to be selected in the file load dialogs. When this is occurring you will see in Finder the file’s “Kind” listed as “Unix Executable File”. To fix this, you can rename the files to a .txt extension, then back to their original .pap or .pab extension, and they will then show as “Document” in Finder. (Power users can use “chmod -x [filename]” in a Terminal window to remove the executable attribute directly.)

- OSX: Program (.pap), bank (.pab) and MIDI-Map (.pam) save/load location now defaults to the ~/Library/Application Support/Admiral Quality/Poly-Ana folder, the same location as your key and settings files. (Note that you are still free to keep your program, bank and MIDI-Map files anywhere you’d like.)

- More improvements to program and bank “chunk” save and recall behavior. Chunks of unexpected size are now recalled, using the minimum of the expected and received sizes.

Let us know how it works for you. And for those of you on OSX, keep in mind the renaming the extension to .txt then back to whatever it was before trick, if any program (.pap) or bank (.pab) files show in the Finder as "Unix Executable File" instead of "Document". (Or use chmod -x [filename] if you're comfortable using the Terminal.)

*Collapses* Zzzzzzzzzz...

[Echoes in the Attic]

I can't load banks. The .pab files are greyed out in the Poly-Ana browser. I renamed my old presets which were displayed as an exec to .txt and back and it didn't matter. The presets supplied with this beta were already a normal document file (not exec) and they couldn't be loaded either. I never tried with earlier betas except for beta 3 which had the same issue.

[AdmiralQuality]

I can't load banks. The .pab files are greyed out in the Poly-Ana browser. I renamed my old presets which were displayed as an exec to .txt and back and it didn't matter. The presets supplied with this beta were already a normal document file (not exec) and they couldn't be loaded either. I never tried with earlier betas except for beta 3 which had the same issue.

Really? What are your host and OSX versions?

And yes, it seems I managed to get the included banks zipped with the right attribute this time. But you're saying they show up greyed out in the Bank Load dialog as well?

[vic_france]

(I sent you an email, with an attached zip file of (hopefully) working .pab files.. they open ok here.
Unfortunately the change of file extension doesn't quite work, because the files then become a "plain text document" (which can't be read any better than the Executables ), instead of a simple "document".
I managed, eventually, to convert the original Unix files into the correct document files (hopefully, zipping them and sending them accross the Internet won't convert them back into something else again!

[AdmiralQuality]

(I sent you an email, with an attached zip file of (hopefully) working .pab files.. they open ok here.
Unfortunately the change of file extension doesn't quite work, because the files then become a "plain text document" (which can't be read any better than the Executables ), instead of a simple "document".
I managed, eventually, to convert the original Unix files into the correct document files (hopefully, zipping them and sending them accross the Internet won't convert them back into something else again!

Yep, got them but I'm not even going to look at them as the included banks (the ones IN the Beta 4.zip) do unzip correctly for me. And they seem to unzip correctly for Echoes in the Attic as well, but he claims to not be able to load them at all. (Echoes, can you doublecheck again and make sure it's actually Beta 4 you're running? It says in the Parameter Display when the plug-in first opens, and in the Options Dialog.)

This is just insane. I'll pick it up in the morning after hopefully a few more reports come in.

[vic_france]

And they seem to unzip correctly for Echoes in the Attic as well, but he claims to not be able to load them at all.

Yes, they unzip, but (same for echoes as for myself) they unzip as "plain text document", whereas, here (and presumably also for him), they have to be a simple "document" (those are two different things )

But, using the Terminal (on the original Unix files) did work for me

[AdmiralQuality]

And they seem to unzip correctly for Echoes in the Attic as well, but he claims to not be able to load them at all.

Yes, they unzip, but (same for echoes as for myself) they unzip as "plain text document", whereas, here (and presumably also for him), they have to be a simple "document" (those are two different things )

Of course they unzip. That's not the question. The question is what attributes they have after they've unzipped. And whether they appear as greyed out or solid in Poly-Ana's Open dialogs. (I assume that once they do show as solid in the Open dialog that nobody's having any trouble loading them, right?)

Echoes said "The presets supplied with this beta were already a normal document file (not exec)", so that doesn't seem to match what you're saying. And I don't see "plain text document" on 10.6.8, I see "Plain Text". And again, when I change the filename's extension back from .txt to the .pab or .pap it was before, it goes to "Document" for me. (Which is also what I get if I chmod -x them.)

[vic_france]

And I don't see "plain text document" on 10.6.8, I see "Plain Text". And again, when I change the filename's extension back from .txt to the .pab or .pap it was before, it goes to "Document" for me. (Which is also what I get if I chmod -x them.)

Maybe a difference between OSX 10.6.8 and later versions (10.8.5 here, and soon even Mavericks will be History! )