looking very nice and clear!

Font size looks good to me this way. With the darker background color, the text color could as well be turned back to green again if you'd prefer that I think

Well I quite like the new colour. I tried it before with the older knob but it didn't look right, but with a dark background this kind of blue looks better than green I think.

Hmm yes, I agree

Definitly better than green.

Alright I've just publicly released v1.0.7 with the bigger blue on black knob displays, also I've backported the changes I brought to the display of decimal places.

That is significantly easier on the eyes. Thanks.

Here's another beta out. The biggest change is node grouping.



You can put band nodes together into a group so you can move them together. When you have at least 2 nodes into the same group a new controller appears (a yellow circle with the group's number written in it) and using it you can move the group around. When a node is in a group you can still move it around as if it wasn't linked, it doesn't change its behaviour. This is basic, I just got it working good enough to use, there's no clear visual indication of which nodes are included (yet, I'm not sure what to do, considering using yellow link lines, but that might look messy, maybe change the nodes colours?) and to set a group you must use the Debug dial to set the group number for each node (so for example you would select a first node and set the Debug dial to 1 to set it to group #1 and then select another node and also set the Debug dial to #1 etc..).

I'm not sure how I'll make group attribution happen in the end, I'm sure there must be a better way than to dial a knob? Although that has the merit of being straightforward and simple.

Now preset saving also records the length of the handles, and that change is both backward and forward compatible (you can open old presets in the beta and open new presets made from the beta in any old version of SplineEQ, however it will naturally disregard the handle lengths).

If anyone wants to test (Windows only) and doesn't have a beta download link yet, pm me.

The obvious would be to drag a selection rectangle around the desired nodes. Shift-click/Shift-drag to add to the current selection, Ctrl-click/Ctrl-drag to toggle.

I think the intuitive behavior would be to have dragging around more than one node create a temporary group which would be effective only until a new selection is made; a button somewhere could then Group (if multiple nodes that are not already a group are selected) or Ungroup (if a numbered group is selected).

I like that idea, no need for extra controls and it's pretty simple. The way I see it just dragging would create a new group, shift/control clicking/dragging would add (or remove) from the group of the currently selected node, and if that node doesn't have a group we'll give him one.


Not sure what any of that means, that sounds potentially complicated? Or I just don't get it. Why a temporary group anyway?

Parallel to what happens when you drag a selection rectangle around objects on the Windows desktop (I'm assuming they didn't change that since XP, which I'm still using); also, selection of objects in a drawing program (at least, vector objects in Paint Shop Pro). Selecting multiple things at once lets you manipulate them together, but as soon as you select something else (not using Shift+ or Ctrl+), the association is lost. You have to Group to make a persistent association in PSP (there's no such thing, as far as I know, on the Windows desktop).

I'm just thinking that one could easily wind up with little numbered dots all over the place that were never intended to stick around... but if you can test it with users, it could turn out that that's not a problem in practice at all.

The blue text was a much needed change! Thank you.

Another update (v1.0.8 ). This time I optimised all the FFTs (the bulk of the processing) to be faster, up to 25% faster (perhaps a bit more, but most of the time it's more like just a few percents of improvement). I did that by replacing the FFT sizes that I assumed to be fast by sizes that I benchmarked to be the fastest. There's also more regularly spaced sizes which is better when adjusting the resolution/delay as it gives more granularity.

That's it. Hey has anyone else noticed the 64-bit build being more CPU efficient than the 32-bit build, mostly at high precision settings?

Can I suggest this layout...makes more sense IMO

I like it, I'll try that but when I'll have options for different window sizes the different options will surely have different layouts anyway but that's a great idea for a wide layout, thanks for that (note that it will have to be wider than that for the preset controls and the extra controls that will be coming in the future versions). All layout ideas are welcome of course.