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

[colin@loomer]

Is there a way to pop up the arpeggiator from the UI? Like an inlet that accepts a signal to "View Object" Thanks.

There is nothing like in the current build, but I do have a prototype where UI modules have (optional) inlets to configure some UI properties. I'll see about this when I look into that feature again.

[mannymang]

Is there a way to pop up the arpeggiator from the UI? Like an inlet that accepts a signal to "View Object" Thanks.

There is nothing like in the current build, but I do have a prototype where UI modules have (optional) inlets to configure some UI properties. I'll see about this when I look into that feature again.

Would it be possible to have the optional inlet on the arpeggiator to view object from a momentary UI button just to activate the window? In my situation I would have multiple arpeggiators in the preset where each momentary button for each arpeggiator would change to that arpeggiator or open the window if not already open. Much appreciated.

[colin@loomer]

It's an easy thing to implement, so I'll see what I can do. I guess the same method should apply to the built-in sequencer modules as well?

[mannymang]

It's an easy thing to implement, so I'll see what I can do. I guess the same method should apply to the built-in sequencer modules as well?

Yes please, I forgot about the sequencers!

[cturner]

Hi Colin- I had another question concerning the realtime interrelationship between Architect's "visual objects" (the ones coded in C++) and Lua scripts. Probably best begun with an example.

Let's say I have an Architect "process" within a preset that is entirely coded with visual objects. It relies on incoming MIDI data to trigger the process, and takes 10 ticks to complete. :-/ In the same preset I have another process that is a Lua script that is triggered at some modulo of an [on every tick] object. The Lua script takes 15 ticks to complete. The two processes in the preset "communicate" through a loads and stores to a shared [memory] object.

My question is when, if the MIDI process begins at tick 0 and the Lua process is triggered at tick 5, do each of these processes complete? Completion being some MIDI output in the first case, and some update to the shared memory in the second. And would it make any difference if the Lua process began at tick 0 and the MIDI process at tick 5?

I've only thought a bit about top-to-bottom, left-to-right order of execution in this case, but I'm guessing there some--if not a large--impact on the answer.

Thanks in advance! Charles

[ThomasHelzle]

Hey Colin,

I read the docs on Note Matching/Coupling and understood that Architect tries to provide Note Offs automatically. Now I encounter hanging notes in my Midi Mangler and am a bit lost how to debug them.
Since I change the pitch and channel of notes and remove some notes completely, it's not a simple 1:1 match.

In Reaktor I had a rather hard time with that as well and in the end created a kind of map for how each incoming note got changed and based on that tried to send correct Note Offs. This works in most cases for me.

In Architect, I didn't try this, since I assumed the system would take care of it automatically. Now that it doesn't really work, I'm not sure how to find out what's wrong, since I don't understand the logic behind the automatic solution - My brain sends an "NOT ENOUGH DATA" error....

The hanging notes happen all the time, no matter if the timeline is playing or not (working in Bitwig Studio, not standalone).
Could you maybe give a bit of background in what cases and how the automatic matching works and when it may fail, and what you recommend to prevent hanging notes?

Here's a link to the Midi Mangler in case you haven't seen it on the other thread already:
https://www.screendream.de/code/toms-midi-mangler

Cheers,

Tom

[mannymang]

Hi Tom, try using "pack note" in place of "pack noteon". See if that will help.

[colin@loomer]

Hi Colin- I had another question concerning the realtime interrelationship between Architect's "visual objects" (the ones coded in C++) and Lua scripts.

I don't quite understand the question (although it is early on a Monday morning so perhaps re-reading it after I've had a coffee may help.) Could you, if possible, give a simpler example?

Regarding the relationship between the Lua script modules and visual modules, the Lua script behaves in exactly the same way as a standard module in terms of when it executes and in terms of order of events, etc.

[colin@loomer]

Hey Colin,

I read the docs on Note Matching/Coupling and understood that Architect tries to provide Note Offs automatically. Now I encounter hanging notes in my Midi Mangler and am a bit lost how to debug them.

I'll take at your patch and see if I can reproduce and/or debug it.

[colin@loomer]

Right, I believe I see your issue, Tom (although please apply the caveats I mentioned to cturner above, and also note: I'm still not had my morning coffee!)

The branch on the top-right of the patch (next to Channel Probability) has note matching enabled. This will ensure that noteoffs will always be sent if previous noteons have been received. However, in your patch, the branch module never receives the previous noteons, so can't match the noteoffs with anything else.

Essentially, you need to route your noteon and noteoff messages through the same branch. You can split them after the branch, and this should match as expected, ensuring that successive noteoffs will be routed as their previous noteons were.

As an aside, the best tip I have for MIDI debugging is that powerhouse coupling of `MIDI to tuple` > `print`. It's a lot easier to debug MIDI messages when you have a history of them in the console.

[ThomasHelzle]

So basically what you are saying is, that I need to do the note probability before I unpack the note, right? Basically with a Midi branch instead of the Data branch?
That will make things actually easier...

What I'm not clear about: Do I then actually need to create the correctly pitched Note Offs myself? with a separate unpack? That was what I hoped to be able to avoid?
I fear I still don't grok how this whole Note-Off logic is supposed to work.
How would I route the noteons and noteoffs through the same branch as you say if I have split them with an unpack?
Until I get that bit, I can't do much useful debugging either, since I simply don't know what to do about what I see coming out...

And thanks to you mannymang, I'll have another look at pack note, but how would I know the duration?

Cheers,

Tom

[cturner]

I don't quite understand the question (although it is early on a Monday morning so perhaps re-reading it after I've had a coffee may help.) Could you, if possible, give a simpler example?

I apologize for the opaque text. The question is really about multiple threads of execution in a preset. You can have a process that responds to incoming MIDI, and one that occurs at certain ticks of the clock, for example. The question is, if they "happen together" and execution would theoretically occur in parallel, what actually happens?

[colin@loomer]

I apologize for the opaque text. The question is really about multiple threads of execution in a preset. You can have a process that responds to incoming MIDI, and one that occurs at certain ticks of the clock, for example. The question is, if they "happen together" and execution would theoretically occur in parallel, what actually happens?

Thanks - that's much clearer, now I understand!

The basic answer is that in a preset graph, everything is ordered entirely by the standard top-to-bottom, left-to-right order. If two (external) things happen at the same time - multiple MIDI inputs both receiving MIDI notes, to lift your example - then the module with the lowest event source order will generates graph events first. You can view the module ordering with the "visual options" (eye icon) on the top right of the graph toolbar. Because of this, there is no such thing as simultaneous events - an event is always given the chance to entirely finish before the next event source module is considered.

[cturner]

Because of this, there is no such thing as simultaneous events - an event is always given the chance to entirely finish before the next event source module is considered.

Thanks, Colin, very helpful. And yes, the visual display of execution order via the eye icon is brilliant! I've had a chance to use it on several occasions to great effect.

All the best, Charles

[colin@loomer]

So basically what you are saying is, that I need to do the note probability before I unpack the note, right? Basically with a Midi branch instead of the Data branch?
That will make things actually easier...

What I'm not clear about: Do I then actually need to create the correctly pitched Note Offs myself? with a separate unpack? That was what I hoped to be able to avoid?

I believe (from a quick look at your patch) that yes, you probably want to move the probability first, trigger it with a `MIDI to signal` and then route using a `MIDI branch`.

No, you won't need to create noteoffs yourself. If you're changing pitch, then I'd use a `set key` module which will deal with the hassles of matching noteoffs with the key of their preceding noteons. Same with `set channel`. (You still will need to pack\unpack the noteon to set the velocity, but I'd just wrap that functionality in a simple little macro.)

If you're having trouble with this, let me know and 'll see if I can help tidy it up when I have a few spare moments.