Architect beta for macOS, Windows, and Linux. 0.10.5 now available

[Soman]

There are still no presets

[colin@loomer]

Still due for the 0.11 releases, which once I've fixed the few 0.10.3 quirks that the last beta uncovered, is all I'll be working on, Architect-wise.

[colin@loomer]

A note delay lane is essential for personalised groove settings etc..,

I'm just trying to scope what it involved in getting this workable. Can I ask: how do you envision this feature working?

My first attempt just had a fixed number of ticks by which amount you could delay each step. But this wasn't really useable as the range of ticks it needed to support were huge: it wasn't possible for me to know if someone wanted to delay by just a few ticks or a few thousand, and having both possibilities in the same bar wasn't intuitive.

So I tried again using metric delays, so delay by 1/128th note, etc, which did work better, I must admit, but made it impossible to specify certain tick values, eg, 3/256th note delays.

So the next two ideas I had were either:
(a) specify delay ticks as a percentage of the current step division. So the default would be a 0% delay, and you could maybe set it up to, say, 100% of the division.
(b) have a specific delay division amount, say 1/1024th note, and then the step value will be a multiple of that, eg, 0/1024th note, 1/1024th note, etc.

I'm leaning heavily towards (a), as I think that's the simpler concept to explain, but I'd be interested in your opinion on this.

[colin@loomer]

FYI: I'm looking to release an update tomorrow that fixes all the bugs I've been made aware of in the 0.10.3 release. It's a balancing act between holding off in case any more bugs breach the surface; and actually getting the fixes out in a reasonable time.

[gentleclockdivider]

A note delay lane is essential for personalised groove settings etc..,

I'm just trying to scope what it involved in getting this workable. Can I ask: how do you envision this feature working?

My first attempt just had a fixed number of ticks by which amount you could delay each step. But this wasn't really useable as the range of ticks it needed to support were huge: it wasn't possible for me to know if someone wanted to delay by just a few ticks or a few thousand, and having both possibilities in the same bar wasn't intuitive.

So I tried again using metric delays, so delay by 1/128th note, etc, which did work better, I must admit, but made it impossible to specify certain tick values, eg, 3/256th note delays.

So the next two ideas I had were either:
(a) specify delay ticks as a percentage of the current step division. So the default would be a 0% delay, and you could maybe set it up to, say, 100% of the division.
(b) have a specific delay division amount, say 1/1024th note, and then the step value will be a multiple of that, eg, 0/1024th note, 1/1024th note, etc.

I'm leaning heavily towards (a), as I think that's the simpler concept to explain, but I'd be interested in your opinion on this.

Percentage sounds fine
So a note with 100% delay should fall/trigger exactly with the next note.
Just curious how you would handle this in a monosequencer ( 100 %) - next step , I assume this note would then be ommited ?

[colin@loomer]

The sequencers overlap notes by a single tick in other cases where this (or a similar) situation occurs, which gives a glide or legato effect. I assume the same would happen here, but let me actually implement the percentage and then get back to you with a definite answer!

[ThomasHelzle]

From the options you listed, percentage sounds like the most versatile option to me, so my vote would go there as well.
Should also work well as a normalised 0-1 value for generative use where absolute values usually are a pain to deal with.
Will it be possible to go outside the 0-100% range? Negative values?

Cheers,

Tom

[colin@loomer]

I think going outside the 100% range is no problem: ultimately, it just says to the note scheduler: instead of playing a note at tick x, play it at tick + n. Negative values are maybe doable (I can certainly see the appeal of being able to shift notes forward in time as well as back), but I'd need to look into that first before confirming.

[colin@loomer]

FYI: I'm looking to release an update tomorrow that fixes all the bugs I've been made aware of in the 0.10.3 release. It's a balancing act between holding off in case any more bugs breach the surface; and actually getting the fixes out in a reasonable time.

An update on this: I may have to push the bug-fix release back a day or so, as I'm not entirely convinced by one of the changes I made, and would rather take a few hours more internal testing. My concern is, if I push out a no-good fix, I'm just going to be rushed to push out a third update pretty much immediately afterwards.

(This isn't definite: I may still make today, but I wouldn't hold your collective breaths.)

[colin@loomer]

Architect beta 0.10.4 is now available to download for macOS, Windows, Linux 32-bit and Linux 64-bit.

This release fixes some bugs and usability issues with 0.10.3, including:

AUDIO CAPTURE
* Fix crash when capturing audio output from the mixer.

MIDI CAPTURE
* Set correct time information on MIDI files captured directly from a track's MIDI output.
* Newly captured MIDI files now base their unique name on their source (either the track name, of the name of the [write to MIDI pool] module.)

MIXER/PLUG-INS
* MIDI from the track input is now passed through to the track output only when no plug-ins on the track consume the MIDI events.
* Fix audio artifacts that could occur in certain complex routing configurations.
* Improved allocation of plug-ins between multiple cores to reduce overall CPU time.
* Certain plug-ins will now correctly choose stereo (over mono) input and output.
* Improved performance when one or more plug-ins require PDC (plug-in delay compensation.)
* Multicore scheduler will now leave more resources available for running Architect and plug-in UIs.
* Restricted range of [mixer parameter] module values to 0.0 -> 1.0, as values outside this range crashed some plug-ins.
* Various improvements to make out-of-process scanning more reliable in certain cases.

[colin@loomer]

I should probably add, I am aware that there are still some issues from 0.10.3 (and earlier) to deal with, but I just wanted to get out an update with the critical fixes included as soon as possible, rather than waiting until every last bug is squashed.

[lnikj]

Please do some presets now Colin. I bought this a year and a half ago (caveat emptor!) to support the cause and I haven't used it at all because I really don't have the foggiest what I am doing

[colin@loomer]

It's still the content of the 0.11 branches, which is now my primary focus, (and of which I was hoping to have out ages ago, but unfortunately the bug fixes and features in 0.10 took way longer than I hoped.) So not much longer of a wait, I can assure you, especially as now 0.10 is pretty stable, so I'm hoping that I won't have too much bug-fixing time eating into 0.11 work.

[lnikj]

It's still the content of the 0.11 branches, which is now my primary focus, (and of which I was hoping to have out ages ago, but unfortunately the bug fixes and features in 0.10 took way longer than I hoped.) So not much longer of a wait, I can assure you, especially as now 0.10 is pretty stable, so I'm hoping that I won't have too much bug-fixing time eating into 0.11 work.

That's great Colin. No need to do a massive release in the first instance - a couple of dozen to look at would be terrific.

[ThomasHelzle]

Yeah, I always thought the all-or-nothing approach isn't really the best. Let them come gradually so we can digest and give feedback...