[h3]A notice to MacOS users[/h3] [i]Regretfully, [b]1.6.2 will not be available on MacOS.[/b] This is for the very lame reason that I told my external developer in charge of MacOS porting that 1.6.1 was definitely the final Keysight update. They have therefore torn down the necessary Unreal Engine setup required to create more builds. My deepest apologies! Very much my fault, but I'm not about to ask them to re-figure-out the outrageous hoops to jump through to get certain plugins working on Mac.[/i] [h1]Surprise![/h1] Hey so err, remember when I boldly announced "no more Keysight 1.X updates, I'm working on Keysight 2.X"? While working through some important bugfixes for 1.6.1, I accidentally snuck in some much-requested features. Whoops! Let's break those down quickly, and then talk about Keysight 2 news. [h2]Colour improvements[/h2] [img]{STEAM_CLAN_IMAGE}/38079779/277149ddd0934f69b1a860320a75cadee5dca6a7.png[/img] Colour modes got a bit of a facelift, and a new addition! The "Channel" colour mode does exactly what you would expect it to do: [b]change colour based on the channel being used by the event.[/b] This is less flexible than using full Channel-to-Preset mapping under Automation, but is far more quick and convenient if you simply want some flat colours to change based on the hand or instrument. Additionally, the Gradient mode (previously called Key Position) now dynamically updates slot name based on which pitch that slot is closest to on the keyboard. Finally, the [b]colour slot limit has been increased from 12 slots all the way to 88![/b] It is incredibly unwieldly to have so many slots, but having 88 slots with Series colour mode allows a specific pitch to have a specific colour in a way that was not previously possible. If doing this, I recommend ensuring Slot 12 is the colour you want all notes to be, as this colour is added to the end of the colour list when adding slots beyond slot 12. [h2]"Point-based force" added to particles[/h2] [img]{STEAM_CLAN_IMAGE}/38079779/05aa9b92bcdc9fedef27cb7b89c8a421d3857f9d.png[/img] By popular request, particles have a new force they can use! "Point-based force" lives under the Wind tab and is a bit of a mouthful, but the snappier "Black hole" name does not quite describe what these new options do. [b]You can now assign a point in space which exerts a force on all particles[/b] with (of course) a lot of configuration. In trying to use this effect myself, it is by far the "hardest" system to get to grips with in Keysight, but it can do some cool new stuff as already [url=https://s.shyked.fr/2023-05-22_SeiG.mp4]proven by Shyked[/url]. [h2]CPU particle mode in Render-to-Video[/h2] [img]{STEAM_CLAN_IMAGE}/38079779/145ba75f8439370ad38076933f7399f31c18a07a.png[/img] Ok so before I get distracted talking about [i]why[/i] this has been such a struggle, the headline: [b]perfect quality renders are now typically more than twice as fast to render using the new CPU particle mode.[/b] This has the caveat that this is only faster than "safe" particle mode, and only works on "reasonable" numbers of particles (systems with greater than 5k particles spawned per second will benefit much less, and may even be slower). Oh, and the [b]resolution limits have been changed: rendering up to 16,384 x 16,384 is now allowed[/b] (at your own risk!). But hey, we have the marketing point of "8k rendering!!11!" now... The technical details for "CPU" mode, for those interested: Keysight's render-to-video (RTV) exports frames using RenderTargets, which exist in the GPU's memory (VRAM). Particles simulate via the GPU and are also stored in VRAM. For [i]some unknown reason[/i], writing to RenderTargets and simulating particles in the same frame causes horrendous particle artifacting, and so for RTV to actually work it needs to write to a RenderTarget for one frame, and then advance the particle simulation on the next frame. This alternation is what "FAST" particle mode does (and may still have a single broken frame here or there); with "SAFE" particle mode being 1-frame-write, 1-frame-simulation, 2-frame-wait as the cycle (which is guaranteed to give perfect frames). The new "CPU" particle mode simulates particles on the CPU and in regular old RAM, thus avoiding the particle artifacting if writing a frame and simulating particles at the same time and guaranteeing non-broken particles on every frame. CPU simulated particles are [i]much[/i] slower than normal GPU simulated particles. If using presets without a high volume of particle spawning, CPU can be even faster than FAST mode, but this is very much a preset-by-preset thing and I encourage you to do some tests! [url=https://egglyberts.live/keysight/changelogs/1-6-2.txt]Full 1.6.2 changelog[/url] [h1]Keysight 2.0 news[/h1] I wanted to give you folks some super early heads-up about how things are going to work. If you have questions or any input, I would love to hear from you in the comments or via [url=https://discord.gg/EHuJKU9393]the Discord![/url] (This is big scary product roadmap stuff and I want to do everything I can to give you the best experience moving forwards) [h3]"Keysight 2" will be a separate product to "Keysight"[/h3] [b]Anyone who owns Keysight at the time of Keysight 2 being released will receive a free license to Keysight 2.[/b] Keysight 1 will continue to exist on Steam and be available to purchase at a slightly lower base price, as my plan is to list Keysight 2 at a higher base price. Anyone purchasing Keysight 1 [i]after[/i] the release of Keysight 2 will not receive a key for Keysight 2. Originally, I had intended to release 2.0 as a free update to Keysight. However, the architecture and flexibility of 2.0 is going to be so radically different that I will not be able to support up-converting 1.X data. Therefore, if I did release 2.0 as an update to Keysight then it would cause a huge headache to any user opening Keysight post-update and suddenly needing to rebuild all their data (unless they manually downgrade via Beta branches back to 1.X). Having a separate product of Keysight 2 allows a much better-communicated split between 1.X and 2.X, but I absolutely want to ensure it acts as a "free update" to you existing Keysight users! Hence the free keys. [h3]Keysight 2 has no explicit release date or timeline[/h3] I have very lofty ambitions for 2.0, and that brings with it a lot of big technical questions I have yet to solve! Pre-production and testing of ideas has already begun, but I don't yet even have a concept for how long it's likely to take to rebuild everything we currently have (on top of adding new features). Let's go with "probably at least a year". [h3]Keysight 2 is a very open development process[/h3] Interested to see how things are going? I am regularly opening up 2.X feedback discussion threads in [url=https://discord.gg/EHuJKU9393]the Discord[/url] and adjusting the design based on thoughts from users like you! Additionally, I will occasionally stream development and have shared various design documents [url=https://docs.google.com/spreadsheets/d/1AkK--hCMhn8efx_4MDjybn9SnrwJkAV88MFaczlA4hw/ ](like this one outlining the planned data structure)[/url]. [h3]Keysight 2 will be very exciting[/h3] Disclaimer: everything is subject to change, and no discussion of a planned feature should be taken as a promise that this feature will eventually exist. With that out of the way, here's some things to fire the imagination! [list] [*] We are, of course, using Unreal Engine 5 for Keysight 2. The typical big-ticket features like Nanite and Lumen are less relevant to Keysight, but there is an experimental new engine feature called Substrate for building materials. And oh man, Keysight 2 materials are going to be [i]exquisite![/i] [*] HeapUnderflow, the external developer responsible for all the actually-difficult tool development for Keysight (like midi file reading, render to video, preset import/export), is working closely with me to "nativise" all tools directly into the engine itself. This brings a host of back-end benefits to make development for me easier, but also brings a huge speed increase to those systems! As an example, the proof-of-concept midi file importing now appears to be upwards of 10x faster and capable of handling larger files. [*] Automation will be a major focus for the general data architecture of Keysight 2. This is very difficult for me to explain succinctly, but the idea is as follows: every menu action in Keysight can also be performed through an "Automation action", and these Actions can be triggered by a variety of inputs. Actions can also smoothly set a variable [i]over time[/i], allowing [i]every single setting in Keysight to become animated.[/i] [*] Following the ease and popularity of .KSpreset files, we will be replacing the awkward "basic / advanced" menu switching in Keysight 1 with a "template -> customise" workflow for every object and effect, and then allow these templates to be exported. The dream is to allow people to share just things like a ".KSnote" or ".KSmaterial" to let beginner users snap together pre-made elements rather than operate within the janky confines of Basic mode; suffer through Advanced mode; or use someone else's preset completely as-is. [/list]There is, of course, so much more I could talk about. But rather than do that, I'll get back to actually building it! Keysight 1 has been a great exploration into the design space of midi visualization and I am quite proud of what has been built, but there are so many lessons and ideas that I am excited to build into the foundations of something new. Watch this space! Happy Keysighting <3