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

[colin@loomer]

Like cturner, I wonder about the node search as well. In all other node based software I use, a certain key has to be pressed to open the node list. In Houdini & Cables.gl it's TAB, in some it was SPACE (which wouldn't work in Architect).
This has the benefit of:
a.) leaving all those letters free as shortcuts and
b.) allows to enter whatever letter or special character one needs without colliding with other stuff, since after pressing TAB, the focus is clearly inside of a text field.

Good idea, I'll look into this. I may be able to support both: having a dedicated key that brings up the dialog with an empty search field, and also still allowing generic key presses to begin a search. This doesn't necessarily "waste" shortcuts because only unmodified key presses open this dialog.

(As an aside, I also need to display and allow users to customise all these keyboard shortcuts. Providing a default set that works on every host or every platform is a fool's errand, but at least if they can be customised then you can work around whatever key presses are greedily consumed by the host before Architect has a chance to respond to them.)

[colin@loomer]

Hi Colin- I'm a little mystified by this:

...

Could certainly be my code, but I'm really scratching my head here.

All becomes clear if you turn on Visual Options > Show Order > Event Destination.

Your [for] module calls the [modulo], which then calls the [==], which then calls [pack tuple]. After this, your [for] module then sends its data to the left [pack tuple] inlet.

Essentially, you just need to send the data to the [pack tuple]'s left inlet before you begin the [modulo] (which ultimately calls the [pack tuple]); many ways to do this, but the easiest is just to use an explicit [data order] directly after the [for] and connect its left outlet to the [pack tuple] and the right outlet to [modulo].

Hope that clears it up, but if not then I can post a screenshot and/or modified preset for you.

[cturner]

Thanks Colin, I guess I'm still looking at Architect through Max/MSP-colored glasses. And I'm still confused.

I assumed Architect has left-to-right, top-to-bottom, depth first execution order. So my analysis would be:

[for] sends data out its outlet, and it's received by [FOR index], [pack tuple], [modulo]'s "a" inlet, and finally by [modulo]'s "call" inlet.

The "call" to [modulo] starts that processing branch, which eventually reaches [pack tuple]. [pack tuple]'s "0" inlet has already been latched with data as above. The chain (ie the outlet of [==]) then supplies the data for the "1" inlet and a signal to the "call" inlet.

So there's something I don't understand about order of execution that explains why in this fragment, [for]'s outlet populates [pack tuple]'s "0" inlet after it's "call". Further, I don't see how I could understand that from the Event Destination display, which I use quite a lot.

What is it about Architect's order of execution that I don't understand?

Thanks for looking into this for me. All the best!

[colin@loomer]

Thanks Colin, I guess I'm still looking at Architect through Max/MSP-colored glasses.
I assumed Architect has left-to-right, top-to-bottom, depth first execution order

Architect orders top-to-bottom, then left-to-right. I'm guessing that MAX is left-to-right, top-to-bottom, although I can't quite remember?

[cturner]

That would be correct: my fragment would work in Max.

Still trying to get my head around when [for] supplies data to [pack tuple], but I’m sure I’ll get clarity.

It’s interesting that for the most part, these differences don’t matter. Surprising that it’s taken me this long to hit an edge-case.

EDIT: Simplest fix is just to remove the “call” cord from [==]’s outlet, and have [for] do that job:



Thanks again for your help!

[colin@loomer]

I did at one point have left-to-right, top-to-bottom, but when I switched to top-to-bottom, left-to-right, I found I have far fewer needs of ordering modules (and, as you've noted, edge cases.)

(EDIT: This is in the original graph, not the one with the solution you suggested above.)

Let me break it down. The events that fire when [for] gets a signal are:

Code: Select all

* [for] => [FOR index] print
* [for] => [modulo] left inlet. This happens before the [for] => [pack tuple] because the [modulo] is above [pack tuple]. Event destination is ordered top-to-bottom.
* [for] => [modulo] right inlet. This calls the [modulo]
* [modulo] => [==] left inlet
* [modulo] => [==] right inlet. This calls the [==]
* [==] => [pack tuple] right inlet. This calls the [pack tuple]
* [pack tuple] => [Tuple] print
* [for] => [pack tuple] left inlet. This is the bug, in that [pack tuple] receives the for indices after the event to its right inlet.

[colin@loomer]

Yes, your solution is another way of doing it, plus you've one module less than me so you win this round, cturner.

[cturner]

Let me break it down. The events that fire when [for] gets a signal are:

This was very helpful in making things concrete for me, thanks.

My final question about all this is the error that was thrown. The console screenshot in the first post gave an "undefined" error. This is the first time I've seen such a thing. Mostly I get "missing argument" and a red X. Is there more to be said about this?

Bon Ouikend!

[cturner]

You win this round, cturner.

Let me assure you it wasn't intentional. ;-)

[colin@loomer]

My final question about all this is the error that was thrown. The console screenshot in the first post gave an "undefined" error. This is the first time I've seen such a thing. Mostly I get "missing argument" and a red X. Is there more to be said about this?

"Undefined" is a (rarely-used) type that is used to represent an unspecified value. There are a handful of places you may see one in the wild, and [pack tuple] is one of them. If you call [pack tuple] without first setting a tuple's element, that element will be undefined.

Other than that, undefined is a normal type. You can create them with [data] modules, or in Lua with arc.undefined.new(), or using an [undefined] module. They evaluate to falsy. You can detect them with the [is undefined] module (and their absence with [is not undefined].)

I guess the most common place you may get an undefined is when you try to read something from a MIDI type that doesn't define it. For example, if you pass a sysex MIDI event to a [get channel], it will return undefined because sysex doesn't have a channel. Or if you try to read from a [latch] or from a [memory] module without first giving these modules a valued item.

[cturner]

Thnx.

This to me has a satisfying look:

[mannymang]

Hi Colin, wanted to report back about the mixer meters... It's down to 2 possibilities that I can see. One is the audio driver, only happens when Architect is set to "Windows Audio" so far. The other is the video driver?

I had just opened Architect, played a little of the preset, then started TeamViewer and opened a session. After closing the TeamViewer session, with the TeamViewer application still running, going back to Architect, the meters were maxed-out. Thank you!

Noted, thanks. I'll look into getting a TeamViewer setup, and see if I can reproduce. Just to clarify, are you running Architect on the TeamViewer host machine, or client machine?

Host. The client machine needs to be producing audio when you log in.

EDIT: The client doesn't need to be producing audio.

[mannymang]

Hi Colin,

I there a module that's the opposite of the "once" module? I'd like to try blocking the first event, but allow all the rest.

Thanks

[colin@loomer]

Host. The client machine needs to be producing audio when you log in.
EDIT: The client doesn't need to be producing audio.

Schrödinger's bug report.

Seriously though, thanks. I've got TeamViewer setup now so I can have a stab at reproducing this.

[colin@loomer]

I there a module that's the opposite of the "once" module? I'd like to try blocking the first event, but allow all the rest.

There isn't (yet), but I've add a note about this. (I think) you could make such a macro with a [once] module and a [branch]. Let me know if this escapes you and if so, I can see if I can build you one.