Polygonius

The ESC-key is a "multi-tool". Its also meaning "close current float-window", so keep this in mind. If you use ESC and your last mouse-action was eg. removing a the brush-panel.... ESC will close the brush-panel instead deselect. So focus your layer first, before hit ESC.

I´m as JUST AP-owner and mainly "creative Photo-editor" and i am happy about AD and LR elements in AP. At least on the first view. In second view, this an expansive "giveaway". Most of my "design"-wishes are covered just by AP. So why should i buy AD too???? Or on the other hand, mainly "Designer" are happy about AP functions in AD. So why should they buy AP too? I do not need any Publisher and i do not need any After Effects and i do not need any Lightroom (as develop-cabin, but i would love and buy a Affinity-Bridge, just for handling and thousand of thousands files) . . But that just me. Other People have exactly different focus than me. Affinity goes the way from all a little bit more, than a little bit in all "brother-apps" too implement. Ok, its a nice giveaway, i do not say know, maybe anytime i will even use this. (In my case, i have never used RAW-persona)... and other AP people has never used any shape in AP except rectangel or circle... or even this not. What i want to say: All Affinity-"specials" covers a wide range off familar apps, thats pseudo-ovviously fine and if AFFINITY would have endless ressources... i would say: Prima, go this way next 7000 years. People who thing like this, does not see: There is nothing for nothing! Too implement a pseudo-Lightroom in AP called RAW-persona... i pay this, without needing/using. (As said, i tell on from my view/usage). I pay a well implement/developed feature, i never use... There is nothing to say about some "rudimentary" functionality of familiar features in a Special-app. But for really DEEP time and ressources, there should be a seprate APP instead this all-in-one-swiss-knife concept. Than what happens too really relevant (just) photo-EDITING-aspects (like macro-development or brush-concept...) when the ressources are bundled to a more less strange, other app with other main-focuss? A Raw-Persona seems to be a nice giveaway, but i have to sell indirect, by resource-focus of such things, instead to focus on core-features of JUST an "Editor/creative photo-app". A Lightroom is a Lightroom and an creative EDItor is a creative Editor and a Design-App is a Design-App... all should have BASE features from each other... but in the MAINLY core, each APP should be a really specialist, not the brother from each other with just different things of how much i offer from my brothers... Just for example: A separete, high special Lightroom with new features, would brings you more new customers as a little bit LR inside AP. Except "Schnäppchenjäger"... most people prefer innovativ, really high core-develop-special-apps before dozens of swiss-knifes, which all a little bit, but nothing really excellent does. I guess a special Lightroom team (for exampel) would bring BOOTH apps AP and your LR to better results. And it would bring new customers for booth apps! MAINLY AP-user would love eg. new macro-possibiltys and MAINLY LRer would love its new environment and new special adjustments... OUTSIDE from this. For a really hand-in-hand-SUITE there should be a file-manager like BRIDGE. Not more, just a smart-file-manager that i can easy switch from one specialist to another specialist inside the modules of my "SUITE". Each SUITE_Module(special app) offers me ALL relavant files in the same structure and last state in each other module. the price for this should be inside each special app, anti-kulmunativ, lets say ONE app covers this hidden product with part of XY for complete SUITE.. if you have 2 apps/modules you paid always a little bit more of this. And so on. Same for "MODULES". But read first next: "PERSONAS" could be fresh way, IF you thing of it as SEPARATE MODULES, which all ARE extra-pay-modules are, all have its more/less resource/develop-teams... i can use RAW/LR in FULL functionality but i have to pay extra, for this module in my personell SUITE! Example: I (as mainly creative Photo-editor/tweaker) i EXCEPT a litttle bit functionality from ALL other apps in my app, like texting, shaping, brushing, rawing... But RUDIMENTARY functionality of this. IF i need MORE functions of other specialist i can EXTRA-Buy a module. Please be fair and let cost just the new stuff/ the difference. AD has lot of AP features and viceversa. So i pay just the difference. And if i use APub too, so i maybe have as AD and AP -module-owner just have too pay 33%... Maybe 56% will buy a whole all-in-one SUITE and become 10% extra off... But however, in which constelation ever, YOU will win, SUITE-buyers will and purist like me, will also win. Its not necassry or wished, that AP is also a half AD and a 70% LR. Its enough, that AP has SOME rudimentary features frome there and there and there... If i like/Need more i can buy the FULL or a SEMI-Version frome there and there and there... If i need all a can buy THE SUITE as allinone for very special price.... I´m sure this buisness-concept with focus of state-of-the-art for each specialist, will bell your cash-register often more AND all custumer will be more happy, cause as more money you have, as more SPECIALIST Developers you can contract.

I cant confirm this (at least in 118 - 120 does not have any fixes/news i need/want, so i overstep this build). My old macros work with all cog i have set. But there is still this very old macro-bug, This Hyper-cog-bug, that, if using old "base/ "sub"-macros" for more complexer-macros ALL "cog-parameter" which uses ONE parameter avaible under the same name in different adjustment/Filter... eg. with the name "radius" inside, or just layer-OPACITY... if there are several of "same" names, in different filters/adjust ... you can not rename each of them individuell. All name-brother-"cogs" will take the same name you give one of them. In "closed" macros (without any sub-macros) this works in 118. But with complex macros (including sub-macros this do not work - but this is not new, this an very old, afaik knowing bug). This, and the non-possibility to RANGE a parameter-slider (like from just 3 - 12 pixel, or inverted from minus 15 to plus 20%....) , are the most open out-of-error-areas in macros. Mostly a slider in macros goes from 1-1000% not just 1-100% and mostly i just need a special range from eg. just 20-35%, but so, the sliders are often useless, only the hit-the-number-field are useful. Its really pitty that Serif does not develop macros more in focus. (BTW: thanks for the new stretching/position possibilities... they are realy great and useful) But in general: There is so many high-potential in macros and so many lacks in the current state.... but it seems more important, that i can crop, crop and crop in handstand and with closed eyes... just by magic-mental-beaming... cropping seems to be the most importand step in all photo-edit-possibilitys... it seems we do cropping so often, each 2 minutes..., here all luxury is high, high number1 of our whole-develope-capacities... Alos all this RAW-stuff! De-coppel all this Light-Room stuff and create a sepreate APP for stuff like this. A new SEPARATE Serif-Lightroom-app, will collect more money for Serif generell and a separate Team, just for Serif-Lightroom, will not waste resources for just AP as EDITOR/creative tool, not as weak Lightroom giveaway.

In 116 and i guess in 118 too (i´am waiting...my slow download...) there is a remember-bug/missbehavior...If i recall AP the settings on "strectch" and "where" a macro should appear are completly forgotten. Quiet inconsistence. Some/most "tools" or other "really deep" will remember the last settings over the current session... some other "tools", scpecial windows... not. The problem is, sometimes for SOME tools and for some windows/panels...adjusts/filter/palletes... i want a remember over the close... and sometimes not. But however in which case i decide, i have for most tools a special "default" i would like to see, each new recall. I do not know how often i have to (reset) each instance of filter or adjustments to the values i need in 90%... That very often not the AP-defaults! So please, give in 1.8 or 2.0 (you did a really good work in the past... a 20- 30 euro--upgrade to 2.0 would be absolut over-fair to me), but please do some lacks with this updrade: - The whole macro-area seems a little bit stepmother-developed -there are lot of bugs or big missbehaviors in it. Some of high-potencial gets wasted... - The whole brush concept is so many years behind eg, FREE Krita... And also ecah "library" stuff- the golden goal is not to HAVE all this items, the golden goal is as fastest and comfortable see/find and jump/select... all this overthousends items... - Please create ONE really, smart preset-system... which is valid for all stuff (tools or life-layers, or panels and sliders... or whatever...) This System should have categorys and subcategorys... fastetd acces to see, selct, rmove, duplicate, delete... and if needed as rubberband-batch... Also the possibility to an item in some smart-folders several times... Nobody needs 53 of this experimental 1980 preset-systems which all mostly offers how many possibiltys they DO NOT have : Did you ever try to move a style? Did you you ever try to move a macro-category, Did you ever try to JUST OVERWRITE a single preset in eg. texture filter???? and so on! No systemof all of this "experiments" has a 21centaury smartness, just only special limitations and limited possibilitys.... You can easy rename a STYLE, but not move... you can easy drag/drop a single macro, but not its category.... (you need dozens times step up/down...) Each "system" has its own limation... often lot of combied limations... no system is smart like as an 21 average system! A brush will always INSTANT overwritten by the same looking window, during another "temp" window will never, never written overwrite this brush, Why not jsut ONE WINDOW and 2 simples buttons"Overwrite"for replace and "new" for a copy of it??? Whats so difficult on this? , if i want my "97%" temporyrly settings really as new/overwritten brush???? ???? ... This and all other preset-"concepts" are so confusing, inelegant, inconsistence, patchwork, hotnailed.... As said i would LOVLEY pay some more euros for 2.0 without NO new features, absolutely no problems -it would be overfair for the great work on other disciplines you have done so far... but i except that such user-confussion/long mouse ways/ unnescarry clicks... child-desases get cured!

Thanks Chris! Aha: It fisrt works if all 3 parameters are set! That was my fault. OK, I understand that dgross needs a dmult (otherwise its a multplication with zero), but why is dglatt also as parameter needed? I can set it to any value, even zero and it works, but if it is missing as parameter, the whole equation does not work? I can even replace the variable dglatt in the eqaution with constant-number, like 1 or zero and it works, but with orign line and this vaiable is missing as parameter it does not work. Okay, thats going to deep here. I will isntead read the manual-chapter again. BTW: thanks for this manual-chapter, its really good written!

If you use the voronoi as live-filter and open its window (again), the second parameter, line-strengt???, will reset to default, instead keeping its given user value! BTW: An option would be fine, that the filter/adjusment-window will dynamically, automatically follow to the current filter/adjusment layer by change. And of course only, if one window is already open. The needed double-click on the thumbnail is not really user-friendly.

Thanks Chris. Would be nice if you post a screenie with the correct syntax/variables so that i see my error!

Maybe i´m to stupid, but are you sure that geman terms work now? I have copy/paste this line from the manual var v=vec2(rx,ry)/w; smoothoschlin(oschcr(v/(dgross*dmult)), dglatt) but nothing happens, neither with dgross or dmult.... as 0.1 variable?????? And of course A is as target defined.

You have to create/select a category before drag/drop from finder. Here it works fine with highsierra!

So you guys have reproduced and do not need the log-file anymore? I do not know where to find.

Tested sometimes, it ALLWAYS crashes (Metal on). Make a quick-mask, brush something in and try to start a macro - 112 will ALLWAYS crash. Well it does not happen if the quickmask is deactivated - you have just the selection (not the quickmask anymore), but sometimes you maybe forget to do this. Have send the report to apple, do you need it extra?

As a GUI-creator for music/VSTi - frontends and dynamic tools, like knobs, faders... multi-text.... i would fisrt of all need simple math/polygon animation, like in the free (java) JKnobman. And this as part of AD/AP. From that point there is a lot possible, but animating in a very simple "math way" should be a basic part of a modern design-tool. So please serif, just study/implement/offer simple "math" animation as your base and offer just this (rudimentary, but solid) as part of an existing product. Wahts about your DAM? How many years, in the meantime, you are not happy with a final "raw-app" or just better-finder-catalouge? In the meantime just a quick&dirty spotlight/windows search "catalogue" inside AP - what is soooo difficult by using existing libraries/tools (eg. spotlight/i-tunes-like-"amart-albums"... are very power-full... search e.g. for all texture-images by name/date/size/last edited/folder....address it in how many "places" you want... its all since years always given AND free to use....)... Alll YOU have to do: just create an Access to this "library" (wich is the finder) .... WE use this imperfect solution, during you can use this as inspiration-tool for how to do an better App! Win/win! Same for tracing... and so on... Please Serif, have some COJONES to "implement" experimental stuff. Just say "Thats experimental, do not use it, if you except a ready feature! . We do not give any warranty or support!" What is better by give absolutely NO solution, instead to give an imperfect meantime-solution, without any warranty/support?

AP does not have independent artbords or stuff like that, which collect "more files" in one "container". In very complex projects, like creating a GUI (with all related stuff inside, not just the GUI) i use "main-chapter-groups" for this. So i have eg. my "static GUI- frontend" and misc folders with dynamic stuff, like all multi-text in another folder, and my knobs, faders.... in another main-chapter-group.... With view collaps/decollapse and view/hide AND lock/unlock... the main-chapter and big backgrounds in each chapter it is ok to work. Not really comfortabel like just artboards, but its usable... i can simulate some views.... edit my dynamic stuff.... i just need ONE file-"global"-color-palette... and each cahnge will transmit to all "sub-files".... And with the great shape/polgon-tools and the fact that 1.7 also have assets in AP.... So, for me there is no current reason to buy AD too. But there would be a reason: If AD would be possible to automate simple/math "animated" stuff, like creating a knob or fader... like in the free java-JKobman app... i would on the same day buy it! But it should be a little bit better than JKnobman. All knobs, faders.... as separate files in one easy project... "global" colors, batch-export like in AP.... Simple animation-automation, that would be a REALLY reason to buy AD too!

Thanx Chris, ok, if the BETA is still 2,3 days active (without installing Final) thats completly fine for me. BTW: what happens with the "serif.beta.user-folder" when installing the final? will it trash automatically by the final-setup or do i have to trash by hand? Maybe the easiest way would be if i duplicate the whole beta user/propcol-folder(content), just before update and replace it with the final. I do not need my 1.67 stuff anymore. Is this possible or will it not run? I mean it should be backward-compatible, and as far i can see, there is no registration-stuff in it, so it should, shouldnt it?

When the final is coming do we get at least 2,3 days to use the BETA further? It will take some time to export/import some of my "propcol" stuff i have created with the BETA. So is there a crossing-time and how long is this?