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

[colin@loomer]

Would it help if it specified which argument was missing?

Sounds like you're struggling a little with a few concepts regarding events, so hopefully the (now sooner, rather than later) documentation will clear this up. I think for people who've used MAX or Pd, the event system is a lot easier to grok than for those coming from, say, a Reaktor angle.

[ThomasHelzle]

I think yes, it would also help if I had an idea what the problem is. And it would help most, if the problem would just go away

I'm also not sure if I want to deal with this grade of manual event shepherding.
My "dream" or "vision" would be a system where the software would deal with this part transparently as far as possible.
Like it building an "object" when a note is received with a unique ID and all the parameters that note needs and then track that object through the system without the user having to deal with it as atomic as Architect seems to handle it.

So far, Architect feels way too much like hardcore engineering to me.
Since we are talking about a musical software, even if a nerdy one, I'd like to be able to try out things intuitively and not think about the precise position of a node or where I get a certain value from to make it work all the time.
If I spend 90% of my time trying to satisfy the needs of a "+" or "*" node, I'm not sure I'll ever create anything creative...

I'm still open to it being me missing a specific simple idea, but seeing that these math node problems bring the whole system to a halt and invalidate the rest of the graph, make me wonder how courageous somebody would have to be to use this for live patching.

Part of my being frustrated of course is the many years of waiting and hoping that this would become my solution to all things Midi. The jury is still out on this, but I hope it can evolve to something that is more inviting to experimentation as the current beta.

Cheers,

Tom

[colin@loomer]

I think I've got the changes locked down for the next beta as there are a few pressing issues that needed to be fixed. But for the succeeding release, I'll get these argument messages tidied up.

The other thing I've toyed with the idea of releasing is full event tracing. I have this internally, and it - as the name suggests - traces every event to the console. Maybe actually being able to see events, and having a history of events, would help you get to grips with the event model? It'll be optional, a debugger option, as converting types to strings for printing is a pretty slow operation, and not the sort of thing you want on all the time.

[ThomasHelzle]

See my comments in the post above. For me the goal would be to try to handle things more graciously and maybe relax the strict event stuff as far as possible and make the nodes more "clever"/"forgiving" and the graph more compact (like the math nodes allowing to enter a static value in the inspector instead of needing data nodes for everything).

[colin@loomer]

I hear you. From your comments, and what I saw of the previous iteration of your MIDI mangler, I think it is just a few conceptual things that need to fall into place for you, and that, hopefully, is something I can address with better documentation and examples.

(By the way, if you post the latest MIDI mangler, I can take a look and see if I can point out where it's going wrong.)

[colin@loomer]

like the math nodes allowing to enter a static value in the inspector instead of needing data nodes for everything.

It's on the roadmap, but not something I'd really want to tackle before 1.0 as there are quite a few other things that need consideration regarding this.

[colin@loomer]

0.9.8 beta is now out, with a few more bug fixes. Download it here for macOS, Windows, and Linux.

- (fix) Fix lock-up that would occur when changing a Lua script module's pin name and then immediately changing the number of inlet or outlet pins on the same Lua script module.
- (fix) Resizing a sequencer's row in the play ui was causing significant CPU spikes as a lot of additional activity was unnecessarily being done in response to the change in size.
- (fix) Parsing of a data's value is now performed in the "C" locale, regardless of the operating system locale.
- (fix) Fixed unlikely race condition that could affect tracing from a Lua script module whilst simultaneously saving a patch or fragment.

[colin@loomer]

AZZIN, if you get a second, could you confirm that this build fixes the issue you were having on your Italian system? Thanks.

[ThomasHelzle]

And for those who encounter undeletable wires: If the wires are set to be transparent, you can no longer delete them.
Colin is onto it...

He also helped me with the errors I was getting and a new version of the Midi Mangler, hopefully without hanging notes, is on the way.

Cheers,

Tom

[colin@loomer]

No problem at all, Tom. As always, appreciate the feedback, as well as the awesome MIDI mangler tool.

[ThomasHelzle]

New version of the Midi Mangler is up: viewtopic.php?p=7292197#p7292197
I'll now stop spamming this thread.

Cheers,

Tom

[AZZIN]

AZZIN, if you get a second, could you confirm that this build fixes the issue you were having on your Italian system? Thanks.

It works perfectly now. Thanks for the fix.
Alberto

[cturner]

Hi Colin- Can you tell me whether it's possible, from just the Graph panel, to set up a [mono step sequencer] to work as a one-shot, triggered by a signal? Or true/false condition? I'm not so interested in how to program such a thing, but can't figure out whether a sequencer's properties can be configured that way at all.

Barring that, could you post a very quick description of how the "conduct", "auto/play q(uantization)", "control action" and "resume" properties interrelate? I think I understand the Play/Timeline aspects, but Modulate? Is Transport Modulation at all dependent on that setting?

Thanks! Charles

[colin@loomer]

You can indeed Charles.

* Show the modulation inlets (under Pattern)
* Set the Transport > Conduct to Modulate and the Transport > Control Action to One-Shot
* Send the pattern number that you wish to play to the "play pattern index" inlet
* Start the pattern playing with a signal to the "play pattern control" inlet.

If you're struggling, let me know and I'll post a quick example patch for you.

Essentially, conduct specifies what controls the sequencer. "Auto" will just play the current pattern, so it's a good starting point for when you first place a new sequencer down, or just want a repeated pattern. "Play" allows you to control it with either the main Play grid, or the mini pattern window to the left of a sequencer. "Timeline" syncs it to the timeline view, whilst "modulate" gives you total control via the aforementioned modulation inlets.

These settings don't much interact with the other settings you mentioned, barring that when conduct is set to "Timeline" a lot of the "Control Action" options are disabled. Which makes sense, if you think about it: if you want a one-shot loop on the Timeline, you'll just set the clip to the length of one-shot. Same with "Auto", which just plays repeatedly in a loop.

[colin@loomer]

It works perfectly now. Thanks for the fix.
Alberto

Thank YOU more like. If you hadn't made that video, I'd never have tracked this down. Cheers, Alberto.