Jump to content
You must now use your email address to sign in [click for more info] ×

shushustorm

Members
  • Posts

    367
  • Joined

  • Last visited

Everything posted by shushustorm

  1. ..and that might not even work on his machine.. so that he has to buy and setup a new machine, with other software possibly not working any more due to OS update? .. Just to be able to be compatible?
  2. Yes. And a way to rearrange their order. (If that's not a V2 feature already; I'm still using V1.)
  3. Didn't work on iPad when I tried. If they didn't change the very fundamentals of their apps, it should be rather straight forward, since they already have their V1 file export algorithms in V1. They just need to write some exceptions for V2 features to convert that to V1 compatible data. If they went crazy on the whole way they manage things, it'd be a huge undertaking, sure, but then I'd question why they changed a clearly running system.
  4. No, OP did not: V2 should be able to import (which it already does) and export V1 files. Not vice versa. And I absolutely agree with that. Similarly to OP, I could use V2 on iPad if I could export V1 files to use on Mac (running an OS unsupported by V2). Besides, it would make the instability of V2 less of a burden, because one could always go back to V1 if needed. Right now, having purchased the whole V2 suite, I can only make use of V2 Designer on iPad, and only for knife and shape builder and port the vectors to V1. Quite limited. Not to mention user base fragmentation, but I guess I've sent enough feedback.
  5. If by that, you mean the iPad version of Affinity apps, then yes, to some degree. But that's not the point. The issues on iPad aren't present because the iPad doesn't allow it. That's because Serif's focus is on desktop. That's exactly what I said earlier. The smaller the screen, the less important to Serif. Not the less capable the devices. That's why suggesting an iPhone version makes sense from a user perspective. Not necessarily business wise, because maybe too small of a user base, but I can't comment on that.
  6. V1 works nicely on my iPad mini 5 (7.9'', 2019) without struggling or UI cutoff, which neither of V2 manages on a 9.5'' iPad. I'd say software makes itself great. It's less about hardware. There are Windows machines running Affinity with weaker specs than what you have on an iPhone. Besides, there are Vectornator and Amadine, which clearly are great examples of how this can be done on smaller screens in terms of UI. Serif developed UI specifically for iPad. Then they released for iPad. Why wouldn't they specifically design UI for iPhone? It's not bound by the desktop UI. You have to do UI from scratch, sure. It's work. And that's the only valid argument I can see: Too little estimated sales for too much work. That'd be a valid point. Anyway, the devices sure are capable of handling Affinity. You just need proper UI.
  7. I still think this would be awesome. (Full versions of Affinity, not just a viewer app; then again, they still don't even let you record macros on iPad, yet work on scripting for desktop. I guess the bigger the screen, the more it is a priority to Serif.) For reference:
  8. Hey everyone! Not using Publisher V2 myself, but if the behaviour is still the same with V2, I'd like to suggest a solution. What happens: When moving a folder containting a publisher file and linked resources (images), all the links break. This happens when I move data from one device to another or I simply want to rename a folder or move it in the path hierarchy. What I can do: Now I need to specify each folder containing images separately at least once to make Publisher load all files in that folder, going from "missing" status to "OK" (or similar). What should be possible: Let's say I got Images/2023/Bunny.png Images/2022/Bunny.png and I want all images to be relinked, I'd just like to specify Images/ and Publisher searches all sub folders for linked images. Otherwise, this can take hours - even adding up when you continously need to move things - what could essentially be a one click situation. Best wishes, Shu
  9. Well yes, that, combined with not being able to boot with an internal drive that failed, makes me want to use those Macs from external only. So I don't run into swelling batteries anymore (which I used to get and you can't boot without a battery since MBP 2015 either.... so similar issue), nor do I want SSD failures that turn the Mac into a brick.
  10. @v_kyr @Chills That's great info! Well yes, I indeed think 16GB could make sense to make things a little more future proof. My 2015 Macbooks run on 16GB and 8GB. Can't say I'm hitting a bottleneck with 8GB even for some heavier 3D modeling, but still. It makes sense from a cost perspective. But I wouldn't be upping the internal storage at all. I'd rather buy a third Mini (more total computation power) than upping the internal SSD of two of them. Given that I would be running the OS as well as all the data IO externally, I don't see a point in increasing internal capacity. In fact, unless I'm missing something, I would't be using it until my external one dies and I'd have to temporarily use the internal one to duplicate from a backup to a new one that I boot from externally. Or is the internal one used for memory management even if I am booting externally? I do write a lot of data externally, so if chunks of that end up on the internal one, I don't see a long life span for those machines.
  11. Thanks for your replies! @v_kyr I'll have a look at that! Thanks! @Chills I do like to go with officially supported behaviour. The reason I do still use macOS is that I still do find the OS more stable than others I tried. The difference gets slimmer year by year, but I still like the stability of macOS in its "official" form. That said, I wouldn't mind roasting the internal SSD some time down the line so much, as long as I can still boot externally (and access via ethernet from another Mac for headless rendering). Interesting! Not really my focus, since if one SSD of one Mini fails, chances are, another one's SSD fails as well (I may be purchasing more than one and let one just run for rendering). But still, interesting!
  12. This topic is quite interesting. I don't really require a lot of RAM myself, nor huge amounts of storage, so this machine, especially in its base version (or maybe I'd throw in 16GB RAM), may be quite interesting in terms of cost efficiency (I'm doing a lot of rendering and code compiling). I don't mind slower read and write speeds. But I do want a machine I can still use 10 years from now. But some posts here are concerning in terms of SSD wear. So I'd like to ask, in case someone knows: Using the M2 Mini, - can you boot from an external drive? - can you boot from an external drive once the internal drive fails?
  13. Alright, last post of mine here, since I now do understand what you mean, yet I find @R C-Rs wording somewhat confusing. You do mean it does matter whether you choose mm or px, right? Because you do think, depending on the chosen unit, it should behave differently and keep the chosen unit unchanged, whereas the other factor (be it pixel when mm is chosen or mm when px is chosen) changes. If that is the intent of this topic, then yes, alright, it may be a bug. Still I do think if that's really intended, it's highly obfuscated (no word of resampling anywhere) behaviour for something that's possibly a document crippling operation with loss of data.
  14. @Patrick Connor Thanks! Worked nicely! Just edited the post!
  15. Thanks for the official statement, @Patrick Connor ! It's alright when you know the system, but without explanation, you never know what the software's company will do. And you generally never know when Apple decides to deprecate, say, 64bit for 128bit or decide it's been too much of a while without an update for the app. But it's great to at least rule out one of those scenarios.
  16. Everyone wants the same behaviour in all Affinity apps, yet I mustn't quote the Photo docs, which clearly state the issue mentioned here is intended. What's a non-pixel document? Any document not made of vectors or text data is made of pixels. Do you mean a document that, within the document setup, has one of the real world sizes set for editing? I really tried understanding this, but I have no clue what this is supposed to mean. The first sentence mixes real world dimensions and pixel counts, which don't compare. The second sentence, if taken by its words, would mean that, for example, mm change to m instead of changing the values, which I don't think would make sense in any case, nor that you meant it like that, yet I fail to interpret it differently. All I can say, and that for certain, a DPI decrease either means - real world size increase (1) or - pixel count decrease (2) (loss of data) because pixel density [dpi] = number [px] / distance [inch] and that, typically, you can choose between resizing (1) and resampling (2), leading to the according changes. Despite seeming different opinions I find this exhausting just like ,,,. So I'm out of here as well.
  17. Interesting! I thought macOS had the same restriction as iOS when managing devices using iTunes, but I guess you can indeed install to unlimited devices. Great to know! Thanks!
  18. That's what I said: I just don't think the result for the given input is surprising and, given that your point, just as mine, was to have non destructive results, - when not given an option - changing real world dimensions makes more sense than changing px count. That's all I said. But, let's see if Serif answers this. Doesn't make a lot of sense discussing without official statements whether there just might be a checkbox missing or not.
  19. That would be just a further argument for why it changes real world dimensions rather than px count. And one of those has to be changed when changing DPI.
  20. I'd say there's a checkbox missing to choose resampling or not. If not chosen, this topic's behaviour should be normal. If it is, the pixel count should change instead. That said, with the option missing entirely, I'd say it makes more sense to change the size than the pixel count, because why would you lower DPI? To get more real world space. Besides, changing pixel count is destructive and if used incorrectly, will lead to data loss. And if you're purely using data digitally, DPI as well as real world size aren't relevant at all, since the display specifies that, not a file. (Needless to say, it's quite confusing having the export persona depend on DPI settings. But that's a different matter.) EDIT: Oh wait, there is a Resampling feature. So yes, the results discussed here are to be expected when Resizing. As stated in the docs: " Scaling Scaling will embed a specific print resolution into an image's metadata to force it to print at a specific dpi (e.g. 300 dpi). The image's pixel dimensions remain unaffected. " (source: https://affinity.help/photo2/en-US.lproj/index.html?page=pages/SizeTransform/imageSize.html?title=Changing image size , underlined by me) If DPI changes and px is constant, real world size must change: DPI = px / inch Not a bug, but expected. And, if you're asking me, it makes perfect sense.
  21. Thanks for your replies, @walt.farrell and @NotMyFault ! I read as well that they keep developing OS bug fixing for V1, so yes, that does indeed mean they'll have to keep at least the latest build of V1 online! So if I decide to buy a Mac in a few months' time, I should still be able to download V1 without having to resort to duplicating a backup and restore from that! (Currently thinking about starting a fresh install for once!)
  22. @iuli @walt.farrell Thanks for the info! That does make sense!
  23. Well yes, sure. Maybe some day, maybe not! I think the Pi would make an argument for Linux. Whether it's an argument to consider, that's, of course, up to Serif.
  24. Well, here is the thing: There are 3 stages: - Visibility on the App Store (V1 is invisible) - Apple Purchase History (everything keeps being on there, nothing is ever deleted) - Availability for redownloading (Devs and Apple can pull an app entirely. Even when something shows in the purchase history, it's not guaranteed to offer a download; sometimes, the cloud button's missing, sometimes it doesn't result in downloading.)
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.