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

[colin@loomer]

If you could gIve me an example of something you feel would be trivial in Max, yet difficult in Architect, I'd be interested to do a direct comparison and see how I can make this stuff easier. Thanks!

[bronswerk]

Hi Colin,
of course your question is perfectly legit but I would have a hard time to actually give you some real world example. I'm totally out of programming since 2 years now. But the feeling I had from the beginning was not good. I had somewhat the intention to make a small version of my Improvisor program. The idea was to make a chordrecognition tool and use sophisticated transposition schemes to manipulate running sequences be it sequences inside Architect or in the host daw. The realtime recording of sequences (as in Improvisor) was omitted.

What bugged me most was the left-to-right event order of objects. In this way you can never neatly line up objects because the last right most inlet is the "bang" so to say. In Max this is the other way around exactly for this reason. As soon as I found out about this I knew my patches would be very hard to understand.

[colin@loomer]

You're not the first Maxer to gripe about the inlet order. I must admit, I adjusted easily, but obviously my experience is not the same as everyone's. Last I checked I think I came to the conclusion that I could switch inlet order without breaking compatibility: but leave it with me, and I'll look into the implications of adopting the Max way and then put my conclusions to the community and see what the consensus would be.

[colin@loomer]

And thanks for the feedback, by the way: very much appreciated.

[ThomasHelzle]

One thing that would help a lot is some clever way of visualising the flow of events and their order. If we must live with them, I'd at least would want to see more clearly what's happening when.
Since there are three different types of even orders to show, it's very non-intuitive ATM (for me).
If you can come up with a way to show this in a brain friendly form, I think it would be much better to work with.

And: ATM Event-Order numbers are truncated when nodes are small...

TruncatedEventOrder.png

Cheers,

Tom

[colin@loomer]

I had a prototype event watcher that pulsed the order of events on the graph, like nodes travelling down the wires in the event order. Never finished it as I couldn't rationalise the time on a a secondary feature, but it's something that could see a return if it aided in comprehension. Thanks for the bug report, also: I'll see that fixed.

[cturner]

You're not the first Maxer to gripe about the inlet order. I must admit, I adjusted easily, but obviously my experience is not the same as everyone's. Last I checked I think I came to the conclusion that I could switch inlet order without breaking compatibility... and I'll look into the implications of adopting the Max way...

I don't think inlet order addresses the chief differences between Max and Architect's languages. As you said, one adapts to it pretty quickly. There are so many differences between the two, that unless one sets out to port the Max language into Architect, one is always going to be bumping up against significant differences in the way things are done.

With regard to evaluation order--and I may be called out as wrong in my specifics here--the differences in top/bottom execution are bigger than left/right. Take this recent excerpt from my Burraston post in both Max and Architect:





I'm computing three indexes here: the current cell and those to its left and right in a cyclical array. Allowing for the size difference (480 vs 16) roughly:

1) Current index plus 15, modulo 16
2) Current index
3) Current index plus 1, modulo 16

The first thing you'll notice is that the Max version's order in "flipped" from what your mental image of the problem is: the left neighbor has to be computed before the right neighbor, otherwise [zl group 3] won't evaluate correctly. Architect's order preserves the left-to-right image of the problem, of no small importance in a visual language.

The trouble with Architect is that from a bottom/top perspective, without the presence of [order], the current index is produced last in the sequence of three. To solve this without the use of [order] the [[$0, $1, $2]] needs to be below the left neighbor computation, but above the right neighbor computation, which produces a representation that's pretty hard to read.

I think this top/bottom difference between Max and Architect is a far bigger conceptual hurdle than the left/right difference. But I don't think that healing this one difference will suddenly make Architect "easier to program". Some of the other differences highlighted in the screenshots:

In Architect, I'm working with arrays. In Max I'm working with a smattering of bangs, numbers and lists. That said, I think there are many more data types in Architect than in Max, and Max's lack of richness in this area may contribute to its ease of programming.

In Max, fixed arguments can be typed directly into the object. Architect needs separate objects for all its arguments. In Max, one of the data inputs (the left hand one) triggers execution of the object. Architect for the most part has a separate "execution inlet". I think in both these cases, an Architect preset ends up more visually dense than the Max patch, and for a visual language, less dense is preferable.

Not illustrated in my screenshots is Max's system of messages. Max is more object-oriented than Architect. Take Max's [coll] object, which is its eccentric implementation of an array data type. It will respond to the following messages:

bang, integer, float, list, anything, assoc, clear, (mouse), deassoc, delete, dump, end, filetype, flags, goto, insert, insert2, length, max, merge, min, next, nstore, nsub, nth, prev, read, readagain, refer, remove, renumber, renumber2, separate, sort, start, store, sub, subsym, swap, symbol, wclose, write, writeagain

I think Architect actually has a much richer array language, but it comes in the form of individual objects. But messaging could be something that Architect could adopt with benefit, resulting in more expressive code. Architect would also benefit from the ability to query its objects--most importantly the sequencers. Their current "write-only" configuration requires programming a parallel data store in order to have access to the current state of a sequencer. Again, simply querying the sequencer for its state is would be simpler.

Of course Architect is a very young language, and it will grow to encompass everything I've spoken about here. Folks have claimed experience with Max, but that experience doesn't seem to go back far enough to recall that it was a pretty primitive language in the 1990s.

With respect to a quick solution however, I wonder why Architect couldn't adopt Luajit as it's Lua backend? It's dramatically faster than Lua byte code, and people here have announced comfort with Lua programming. Wherever Architect native objects end up, a powerful, standard language would always be a boon. (EDIT: I also enjoyed working with Terra http://terralang.org/ when it first came out.)

[Hez]

Great info cturner, I've never really used Max but it was interesting to read a little about the similarities/differences.

@Colin, this event watcher idea sounds like it would really help me! I obviously wouldn't want to divert dev time from more important things, so more thorough documentation/examples probably makes sense as a first port of call.

Despite my tuple troubles I'm still very excited about Architect, and have a long list of ideas to prototype when I get back round to immersing myself in it!

[ThomasHelzle]

Well presented cturner!

Yeah, not being able to put values directly into the nodes is really cluttering things up and creates potential for errors since the values aren't "just there" in the node without additional order problems. I don't think I've ever seen another node system that doesn't have all the nodes values available "in the node" itself for everything that's static anyway.

And a big +1 for a kind of jit compiled Lua node that can be written into on the fly. Probably the most used node type in Houdini for instance is the "wrangle", a node that executes "VEX", Houdinis extremely optimised scripting language. One does not enter a fullscreen editor, but the node parameter interface is an editor right away, so one can type code easily without being "out" of the node flow... Awesome for all the things where one line of code replaces a dozen nodes!

One more problem: I have Architect installed in C:\Musik\Loomer\Architect
I realised that the standalone wasn't the latest, so I deleted it and re-installed the latest version 0.10.2 to that same directory, but the standalone isn't installed into that same directory. A problem with the installer on Windows 8.1 x64 maybe?

Cheers,

Tom

[cturner]

I found myself unable to sleep last night and ended up writing my previous post without a lot of preparation. I went back this morning to construct a better illustration of what I think is the "typical" Max-user cognitive disconnect with Architect's evaluation order.

Here's the Max fragment shown above pared down to its basics:



The fragment computes the neighbor indices of a 16 element Cellular Automaton array. The [print] results tell the story: the zeroth element has the 15th and 1st elements as neighbors, and so on through the array until we wrap around to 14, 15, 0 at the bottom. (As I mentioned in my previous post, notice that the central computation has to be reversed in Max to obtain a "mentally ordered" representation of the result.)

If we naively port the Max approach into Architect, even compensating for the left-to-right evaluation change, we run into trouble:



(To be honest, I'm still not quite sure what's going on here. More later on this if Colin doesn't beat me to it. Okay, I think I understand now, see bottom of post.)

In my Burraston preset, I used an [order] object to make the evaluation sequence clear, but below, I can change the positioning of objects to get the correct computation:



So for me, the way Architect evaluates top-to-bottom is a bigger disconnect than the left/right switch. The above isn't really a mess: I understand that the elements of [for each] need to be executed at the same vertical level left-to-right. But given the way I've placed the "fixed" arguments to [+] and [modulo], there are a lot of dotted cables in a small space. If I went for this, I'd seriously consider moving the placement of the "fixed" arguments back up above their objects, for clarity's sake.

. . . . . . . . . . . . .

EDIT: Sorry for all the flailing about, but I do think I know why the "bad" example above doesn't work. I relaunched my "bad" example from scratch and got a tenacious "Mixed Types in Array" error. I think this is because in the template [[$0, $1, $2]], when it is called to execute, the $1 value (the current index) hasn't been populated, so it's an array with an uninitialized value. This led me finally to the best solution for the top/bottom execution issue:



It's simply that if the current index--the $1 value input--is last to reach the template, it should trigger template execution, not the [modulo] of the right hand neighbor. Plus it's more legible!

HTH

[colin@loomer]

not being able to put values directly into the nodes is really cluttering things up

That's being worked on: direct constant values for inlets that are 'built-in' to the nodes will be coming, once I've resolved a few outstanding issues with it. Hopefully that will allow a lot of visual clutter to be removed from a great many presets.

And a big +1 for a kind of jit compiled Lua node that can be written into on the fly.

I've changed the way this works in the upcoming release, and I believe it does what you are asking, allowing scripts to be edited 'on-the-fly' without needing to commit a working script.

problem with the installer on Windows 8.1 x64 maybe?

Yes, I believe you reported this before, or certainly something similar. I did start looking into it but never got around to completely fixing it. It's not a difficult problem, so it will get nailed, it's just that installer issues are pains simply because of the turnaround time in building an installer, testing, uninstalling, ensuring everything is actually uninstalled, etc.

I wonder why Architect couldn't adopt Luajit as it's Lua backend? It's dramatically faster than Lua byte code, and people here have announced comfort with Lua programming.

I did have LuaJit support, but it seemed LuaJit support ended permanently with an historic Lua version, and I didn't want to end up committing to a technology with no potential upgrade path. The situation may have changed since, though, so I will see where Luajit stands now and going forward.

I went back this morning to construct a better illustration

Thanks for your great breakdown of the Max vs Architect example: it's given me a clear idea, I feel, of how I can close the gap between these two. Again, it seems inline constants would basically half your module count. (As an aside, there are [data order] and [midi order] modules if you prefer not to rely on module placement to guide event order.)

As always, thanks so much for taking the time for the in-depth feedback and suggestions.

[ThomasHelzle]

I found myself unable to sleep last night and ended up writing my previous post without a lot of preparation. I went back this morning to construct a better illustration of what I think is the "typical" Max-user cognitive disconnect with Architect's evaluation order.

Honestly, to me this is madness.
When there is more effort going into event order than into creating interesting structures, something is wrong at the very base of the system IMO. Especially if that system is targeted at musicians, even if technically inclined ones.

The only reason to use nodes over code is to make things "easier" and more visual. I can't see that here so far.

I personally see untangling that knot as an even higher priority as everything else on my list.

This is exactly the situation I feared when the development of Architect took as long as it did without it being open to user feedback. I totally understand the arguments for it, I've been on the perfection trail before myself, but at this point in time, I strongly believe in things growing naturally from small to big, even with some losses in the process and some growing pains.

Water under the bridge and all that and I really appreciate how open and accommodating you are, Colin, but still I'm somehow sad, since right now, I could really use a strong generative midi application for a major project in my life.
So I evaluate http://www.cables.gl for a while now. It has (web) midi in and out, can be synced, runs in the browser (!), I can write my own nodes in JS and it's nodes and thinking are much closer to Houdini (it's mainly about visuals).
No event order problems at all. May not be timing-perfect but that's not my game anyway.

Sorry if this comes over negatively. It's my sadness speaking.

Cheers,

Tom

[colin@loomer]

I personally see untangling that knot as an even higher priority as everything else on my list.
Sorry if this comes over negatively. It's my sadness speaking.

Absolutely, I hear where you are coming from, and of course getting Architect to be as usable as possible is my goal. I hope to win you over Thomas, which is why I absolutely appreciate the suggestions of those who've taken the time to point out where the product needs refinement.

[ThomasHelzle]

I personally see untangling that knot as an even higher priority as everything else on my list.
Sorry if this comes over negatively. It's my sadness speaking.

Absolutely, I hear where you are coming from, and of course getting Architect to be as usable as possible is my goal. I hope to win you over Thomas, which is why I absolutely appreciate the suggestions of those who've taken the time to point out where the product needs refinement.

Thanks Colin!
I actually hope you will succeed

Here is a screenshot of a "Wrangle" in Houdini in action in a generative project of mine:

HoudiniWrangle.jpg

The upper right is the GUI of the Attribute Wrangle node called "Wrangle_Start" at the lower right where some lines of code do some stuff to points in the scene. This is "live" and I can type into it at any time and see it execute right away.

And as an inspiration for later: Another aspect of this system is the easy creation of input gadgets as a GUI for the code:

HoudiniWrangleUI.jpg

The "chramp(...)" in the code creates the "Width Curve" spline GUI element and the "ch(...)" the "Base Width" slider. All I have to do is type the code for these elements and press the small icon with the slider to the right of the code, then the processor goes through the code and creates all occurrences of UI elements automagically. Makes it very quick and easy to give the nodes a custom GUI.

Cheers,

Tom

[cturner]

I did have LuaJit support, but it seemed LuaJit support ended permanently with an historic Lua version, and I didn't want to end up committing to a technology with no potential upgrade path.

I see from the Terra list archives that I was fooling around with this stuff back in 2013, so my experience is quite old. If an Open source project hasn't been updated for a year, it's good to be wary for its future.

As always, thanks so much for taking the time for the in-depth feedback and suggestions.

You're welcome! In working on all this, I think I've had an Architect aha! moment and spotted another place in my Burraston preset where I have a similar error in execution order.

This seems to make sense to me:

. Max: right-to-left, then top-to-bottom
. Architect: top-to-bottom, then left-to-right

Anyway, if Architect never evolves beyond its current state, it's still my preferred MIDI sequencer!