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

[Taizong]

By the way, when I use the 2 UMX 610s in Reaper's MIDI track assignment menus, Reaper automatically gives them "a" and "b" suffixes (i.e. "UMX 610a" etc) and they can be independently assigned to different tracks.

Slight correction to what I wrote above. Reaper allows you to assign "alias names" to MIDI devices, which is what I did at some point, and is where the UMX 610 "a" and "b" designations come from. Sorry about the incorrect statement. However, Reaper does recognise the input from the two separate devices and allows them to be treated separately in MIDI processing.

[colin@loomer]

Slight correction to what I wrote above...

Many thanks for this (and the previous information.) I *believe* I now know what is causing the problem, and how I can reproduce it. If that is the case, I'll look to get this fixed in the next build.

[Taizong]

Many thanks for this (and the previous information.) I *believe* I now know what is causing the problem, and how I can reproduce it. If that is the case, I'll look to get this fixed in the next build.

Great - standing by to try the next build...

[onailime]

Hello Colin and all,

this is my first post here. I have bought Architect and used it for about a week now.
Although I have not used it as much as other people here, I can already tell it is a fantastic piece of software, and shall I say, an amazing music instrument! In fact it is just what I was looking for, so many many thanks Colin...

I have two major feature requests, which would make Architect really perfect for my needs. It would be great if they could be added to Modulation and Play modes (and why not in Timeline mode?)...

1) add an option to allow that the synchronization is always preserved between the patterns of one sequencer, so that a pattern change does not start the pattern from its beginning, but from the place it would have been if it had been playing (silently in the background) all along.

This has been proposed and discussed previously by cturner, albeit not exactly in the same way, but I think Charles is trying to go to the same place as me. His workaround, a few pages earlier, although interesting, certainly loses the advantages of using patterns.

2) add an option to allow that sequencer pattern change does not occur until the playing pattern has reached its own end.

This is meant to allow non-robotic compositions where sequencers can each drift independently from the DAW tempo its own way, using Transport Modulation "speed", "count", "divide", etc. So, yes chaotic rhythms! (just like the sounds of nature)...

Would that be possible ?

[starflakeprj]

8 months and still not a video presenting what Architect is capable of?

[colin@loomer]

1) add an option to allow that the synchronization is always preserved between the patterns of one sequencer, so that a pattern change does not start the pattern from its beginning, but from the place it would have been if it had been playing (silently in the background) all along.

It is on the roadmap, and I did look into this exact thing for this release. It turned out to be much more work than I anticipated because of a few quirks with how the patterns work internally. But yes, it will be done at some point.

2) add an option to allow that sequencer pattern change does not occur until the playing pattern has reached its own end.

You mean when launching from the play ui, etc? Yes, that's easily done, although I guess it would only apply in modes that have a fixed length. For brownian, or random, for example, there is no clear concept of an "end" of the pattern, although I guess I could base it on the number of steps? Either way, yes, I'll look into it.

[colin@loomer]

8 months and still not a video presenting what Architect is capable of?

No, sorry, I just haven't gotten around to this yet. But users have posted generative audio clips in this thread, as well as to soundcloud and the like.

[starflakeprj]

8 months and still not a video presenting what Architect is capable of?

No, sorry, I just haven't gotten around to this yet. But users have posted generative audio clips in this thread, as well as to soundcloud and the like.

Thanks Colin, I will check them out. Yeah, I know how time works, downloaded the demo but didn't have time to learn how to use it, which is why I have been looking for videos, every once in a while, to get me started

[colin@loomer]

Thanks Colin, I will check them out. Yeah, I know how time works, downloaded the demo but didn't have time to learn how to use it, which is why I have been looking for videos, every once in a while, to get me started

No, thank you for reminding me about the video situation. When I'm caught up in development, bug-fixing, etc, it's sometimes all too easy for me to forget that features and fixes are only half of the product, and that fostering a community and teaching the app is just as important.

[onailime]

1) add an option to allow that the synchronization is always preserved between the patterns of one sequencer, so that a pattern change does not start the pattern from its beginning, but from the place it would have been if it had been playing (silently in the background) all along.

It is on the roadmap, and I did look into this exact thing for this release. It turned out to be much more work than I anticipated because of a few quirks with how the patterns work internally. But yes, it will be done at some point.

Thank you, that will be fantastic !

[onailime]

2) add an option to allow that sequencer pattern change does not occur until the playing pattern has reached its own end.

You mean when launching from the play ui, etc? Yes, that's easily done, although I guess it would only apply in modes that have a fixed length. For brownian, or random, for example, there is no clear concept of an "end" of the pattern, although I guess I could base it on the number of steps? Either way, yes, I'll look into it.

Yes, I mean when playing from the Play UI (or actually when receiving a midi note information on the arrow of a pattern in the Play UI).

So for example, in Play/Gate mode with the new option (let's call it Auto/PlayQ=complete) in the Play UI, I would set pattern 1 launch by note C1 and pattern 2 by note C#1. When I change from note C1 to C#1 the sequencer will wait until pattern 1 is done and only then launch pattern 2.

Regarding cases when pattern length changes all the time due to modulations, would that cause an additional difficulty to simply wait for the pattern to end before changing pattern playback?

[colin@loomer]

let's call it Auto/PlayQ=complete

Yes, that would be the best way of exposing this functionality, I think.

Regarding cases when pattern length changes all the time due to modulations, would that cause an additional difficulty to simply wait for the pattern to end before changing pattern playback?

No, no difficulty whatsoever. Everything is calculated "on the fly" as the built-in Architect sequencers have to deal with all sort of possible real-time modulations.

Tentatively, though, this sounds both trivial to implement and a very useful addition. Thanks.

[Hez]

1) add an option to allow that the synchronization is always preserved between the patterns of one sequencer, so that a pattern change does not start the pattern from its beginning, but from the place it would have been if it had been playing (silently in the background) all along.

It is on the roadmap, and I did look into this exact thing for this release. It turned out to be much more work than I anticipated because of a few quirks with how the patterns work internally. But yes, it will be done at some point.

2) add an option to allow that sequencer pattern change does not occur until the playing pattern has reached its own end.

You mean when launching from the play ui, etc? Yes, that's easily done, although I guess it would only apply in modes that have a fixed length. For brownian, or random, for example, there is no clear concept of an "end" of the pattern, although I guess I could base it on the number of steps? Either way, yes, I'll look into it.

Another vote for pattern continuations when changing index, would be super useful for the generative 'sequence combiner' thing I'm building at the moment! I'm currently splitting it out into one sequence per sequencer so that I can seamlessly switch between them in the middle of patterns, but being able to load groups of sequences into each one ('banks' of similar sequences per sequencer if you like) would be super useful for organisation.

[colin@loomer]

Another vote for pattern continuations when changing index, would be super useful for the generative 'sequence combiner' thing I'm building at the moment! I'm currently splitting it out into one sequence per sequencer so that I can seamlessly switch between them in the middle of patterns, but being able to load groups of sequences into each one ('banks' of similar sequences per sequencer if you like) would be super useful for organisation.

Thank you, and I hear ya! There's certainly enough interest in that issue for me to devote a chunk of development time at getting it added. However, I'm on the cusp of releasing an update, and I think I'd rather bump this request to the next update, as I've already torn out and replaced a worrying amount of pattern code, code of which I'd like to guarantee has not been broken by my changes. (Also, I'm looking to massively reduce the time between updates, adding fewer changes, but with much shorter turnaround.)

[Hez]

Thank you, and I hear ya! There's certainly enough interest in that issue for me to devote a chunk of development time at getting it added. However, I'm on the cusp of releasing an update, and I think I'd rather bump this request to the next update, as I've already torn out and replaced a worrying amount of pattern code, code of which I'd like to guarantee has not been broken by my changes. (Also, I'm looking to massively reduce the time between updates, adding fewer changes, but with much shorter turnaround.)

No worries and no rush, it's fantastic to have feature requests directly responded to by a developer in any way at all! Makes sense re: more frequent releases, I've only done a small amount of software development in my life but I know that feeling when you know you might've changed a little too much since the last release...

On another note (just to be super irritating), are the plans for a looper module still on the table?

Cheers