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

[secretkillerofnames]

Well I bought it... if only to ensure that I don't fly into another rage after setting up a patch that seems to work and adding a plugin that Architect let through but clearly shouldn't have. (It was Ariesverb by the way) #ragequit #saveoftenandalways

[gentleclockdivider]

All feature requests noted, thanks.

As for a 1.5 multiply, you can do a multiply x 3 and divide by 2 for the same effect.

[lickle_emu]

Hi Colin, hopefully a simple request:

Would it be possible for newer versions of Architect to somehow install over the last version? (rather than having to manually select the chosen destination each time)

Also, could you set it up so that users are able to manually select the folder in which presets etc. are stored?

[cturner]

Hi Colin- Would you say something regarding the relative performance of Architect's "visual language" versus Lua scripting? IIRC, the folks at Cycling74 made the point that Max objects had better performance because they were written in C, as opposed to the Javascript interpreter they exposed to users. Of course with MIDI as opposed to audio, relative performance gains may be close to meaningless.

And are you using LuaJit, or does the compile button create Lua bytecode?

[colin@loomer]

Hi Colin, a hopefully simply request:

Would it be possible for newer versions of Architect to somehow install over the last version? (rather than having to manually select the chosen destination each time)

On Windows, you mean? If so, yes, that's already been asked for, so I'll deal it with when I start poking the installers.

Also, could you set it up so that users are able to manually select the folder in which presets etc. are stored?

I'll add it to the feature requests. I have a feeling this would be one of those things that I'd need to think carefully about for risk of breaking something else, but I'll certainly take a look.

[colin@loomer]

Hi Colin- Would you say something regarding the relative performance of Architect's "visual language" versus Lua scripting?

Same applies here, really. "Compile" compiles to Lua bytecode, which is very fast, but the (C++) modules are likely faster than the equivalent in Lua. Another factor is that when Arc objects flow into or out of the Lua script, there is a little bit of conversion going on to prep the objects for Lua-isation.

There are a few other factors too: Lua scripts need to periodically run their own garbage collection, the aggressiveness of which is controlled by how much of the allocated pool has been used up.

But you're right in your summation: MIDI is fast compared to audio, so it's likely not a deal-breaker either way.

[ThomasHelzle]

Hi Colin- Would you say something regarding the relative performance of Architect's "visual language" versus Lua scripting?

Same applies here, really. "Compile" compiles to Lua bytecode, which is very fast, but the (C++) modules are likely faster than the equivalent in Lua. Another factor is that when Arc objects flow into or out of the Lua script, there is a little bit of conversion going on to prep the objects for Lua-isation.

There are a few other factors too: Lua scripts need to periodically run their own garbage collection, the aggressiveness of which is controlled by how much of the allocated pool has been used up.

But you're right in your summation: MIDI is fast compared to audio, so it's likely not a deal-breaker either way.

Is that somehow leveled by the fact that you often need tons of nodes for something you can do in a couple of lines in Lua? Or asked another way: Is there some kind of overhead from handing over data between nodes? You mentioned once that you have some optimisations implemented where nodes avoid having to recreate the data and basically share it, but in the case of for instance my perlin noise, would something like that be actually faster in nodes?

I have to say that I find all the data handling quite awkward with nodes, I never got comfortable with that in Reaktor Core either, so I'll probably use nodes only for things where they represent a kind of more "complete" function (like the swinger or force to scale, and of course the sequencers) but stay away as much as possible from the atomic stuff - way too messy for me .

From your comment I also assume that it's better to have one larger Lua script instead of 10 small ones, right?
That should become especially cool when we can have inspector parameters for scripts and macros and can build more complex über nodes - in my shaders, I used to bundle 10-20 different noise types in one node with a dropdown selecting which one to use via a switch statement...

And how does Architect deal with threading? Is anything running in parallel or is it all singlethreaded?

Any optimisation tips are always welcome!

Cheers,

Tom

[colin@loomer]

Any optimisation tips are always welcome!

I guess there maybe some critical threshold over which a Lua script would beat X number of nodes, but I think there are too many factors at play here to gives estimates general enough to apply to all scenarios. I also think this is probably an indicator that perhaps a built-in profiler, even something as simple as an average % of CPU or milliseconds taken to run the graph would be handy for those - like you - who want to eke out more performance. I do have various profiling tools that I use internally, and (here I go again) exposing them probably wouldn't be a massive job in a future beta build.

The graph is single-threaded. I experimented with multi-threading , but there are so many edge cases and difficult situations to resolve in order to keep things in order, and I just couldn't resolve them to my satisfaction. And once you start adding in code to keep things safe on multiple-threads, performance drops to basically single-threaded equivalence (or worse!) anyway. I resolved then to bump any more stabs at a multi-threaded graph to Architect 2.0.

The main optimisation tip I guess is to only do things when you need to. By that, I mean, if you've got a table module which you are using as data values for a sequencer running at 1/8th notes, you don't need to be reading the table every tick: every 1/8th note will suffice. Other that than, the usual golden rule applies as it does with all optimisation in all languages: a better algorithm will beat micro-optimisations.

[gentleclockdivider]

Another request
Ability to zoom in/out and navigate along the structure view with the mouse.
The shift , ctrl, alt buttons aren't used at all , let's put them to use

[ThomasHelzle]

Makes sense! Thank you

Maybe Multithreading could at one point be done like in most DAWs where individual tracks (with no overlaps/dependencies) run in separate threads?
And if at one point multiple graphs are possible, those could run in individual threads too maybe? We spoke about a kind of tabbed interface for those, that may actually be a way to separate things enough to make them threadsafe?

But all of this is mostly my personal liking of knowing about the best practices and a liking of fast code and not so much a dire need to run 500 instances of Architect...

Thank you!

Tom

[polarity-dnb]

--------------------------------------------------------------------------------
Architect 0.9.3
OS Mac OSX 10.13.6 64-bit
REGION DE language: en
SYSTEM speed: 2800Mhz cores: 8 memory: 16384MB MMX SSE SSE2 SSE3 SSSE3 SSE41 SSE42
DISPLAY 1 area: 0 0 2560 1440 DPI: 72 scale: 1 main
09 Jan 2019 14:25:26 - [0xac133712] Instance started
09 Jan 2019 14:25:26 - [0xac133712] Running as standalone
09 Jan 2019 14:25:26 - [0xac133712] Opening preferences file
09 Jan 2019 14:25:26 - [0xac133712] Preferences opened OK
09 Jan 2019 14:25:26 - [0xac133712] Installing global crash handler
09 Jan 2019 14:25:26 - [0xac133712] Creating filesystem
09 Jan 2019 14:25:26 - [0xac133712] Opening factory presets
09 Jan 2019 14:25:26 - Loading static shared resources
09 Jan 2019 14:25:26 - Loading file framework.lpk
09 Jan 2019 14:25:26 - Reading from bundle uk.co.loomer.architect
09 Jan 2019 14:25:26 - Loading file plugin.lpk
09 Jan 2019 14:25:26 - Reading from bundle uk.co.loomer.architect
09 Jan 2019 14:25:26 - Static shared resources loaded OK
09 Jan 2019 14:25:26 - [0xac133712] Creating document for current state
09 Jan 2019 14:25:26 - [0xac133712] Creating audio renderer
09 Jan 2019 14:25:26 - [0xac133712] Setting up audio processor graph
09 Jan 2019 14:25:26 - [0xac133712] Setting up performance parameters
09 Jan 2019 14:25:26 - [0xac133712] Opening plug-in cache file
09 Jan 2019 14:25:26 - [0xac133712] Populating known plug-ins list
09 Jan 2019 14:25:26 - [0xac133712] Creating preset validator
09 Jan 2019 14:25:26 - [0xac133712] Creating mapping sources and sinks
09 Jan 2019 14:25:26 - [0xac133712] Starting job thread
09 Jan 2019 14:25:26 - [0xac133712] Setting preset state to default
09 Jan 2019 14:25:26 - [0xac133712] Sending playlist to audio thread
09 Jan 2019 14:25:26 - [0xac133712] Creating default mixer nodes
09 Jan 2019 14:25:26 - [0xac133712] Need instance of plug-in Audio Input
09 Jan 2019 14:25:26 - [0xac133712] Creating new instance of plug-in Audio Input
09 Jan 2019 14:25:26 - [0xac133712] Need instance of plug-in Audio Output
09 Jan 2019 14:25:26 - [0xac133712] Creating new instance of plug-in Audio Output
09 Jan 2019 14:25:26 - [0xac133712] Need instance of plug-in Midi Input
09 Jan 2019 14:25:26 - [0xac133712] Creating new instance of plug-in Midi Input
09 Jan 2019 14:25:26 - [0xac133712] Need instance of plug-in Metronome
09 Jan 2019 14:25:26 - [0xac133712] Creating new instance of plug-in Metronome
09 Jan 2019 14:25:26 - [0xac133712] Need instance of plug-in CvOut
09 Jan 2019 14:25:26 - [0xac133712] Creating new instance of plug-in CvOut
09 Jan 2019 14:25:26 - [0xac133712] Need instance of plug-in Master
09 Jan 2019 14:25:26 - [0xac133712] Creating new instance of plug-in Master
09 Jan 2019 14:25:26 - [0xac133712] Need instance of plug-in Level Meter
09 Jan 2019 14:25:26 - [0xac133712] Creating new instance of plug-in Level Meter
09 Jan 2019 14:25:26 - [0xac133712] Need instance of plug-in Stream to File
09 Jan 2019 14:25:26 - [0xac133712] Creating new instance of plug-in Stream to File
09 Jan 2019 14:25:26 - [0xac133712] Done creating default mixer nodes
09 Jan 2019 14:25:26 - [0xac133712] Finished initialisation
09 Jan 2019 14:25:26 - [0xac133712] Creating UI
09 Jan 2019 14:25:26 - 0 Architect 0x000000010fbab1a1 _ZN4juce11SystemStats17getStackBacktraceEv + 65
1 Architect 0x000000010f7a2ae4 _ZN7logging12_GLOBAL__N_1L12crashHandlerEv + 36
2 Architect 0x000000010fbab40a _ZN4juceL11handleCrashEi + 10
3 libsystem_platform.dylib 0x00007fff5dc53f5a _sigtramp + 26
4 ??? 0x000000ff00000000 0x0 + 1095216660480
5 Architect 0x000000010f72a97a _ZN11AudioStream13processBufferEPPKfPPfiRKNSt3__16vectorI5EventNS5_9allocatorIS7_EEEEb + 1882
6 Architect 0x000000010f7862d3 _ZN10PluginCore12processBlockERN4juce11AudioBufferIfEERNS0_10MidiBufferE + 2307
7 Architect 0x000000010fb88f24 _ZN4juce20AudioProcessorPlayer21audioDeviceIOCallbackEPPKfiPPfii + 1508
8 Architect 0x000000010f7d93f1 _ZN6Player21audioDeviceIOCallbackEPPKfiPPfii + 641
9 Architect 0x000000010faf8c75 _ZN4juce18AudioDeviceManager24audioDeviceIOCallbackIntEPPKfiPPfii + 805
10 Architect 0x000000010fafe54a _ZN4juce16CoreAudioClasses17CoreAudioInternal13audioCallbackEPK15AudioBufferListPS2_ + 298
11 Architect 0x000000010fafe413 _ZN4juce16CoreAudioClasses17CoreAudioInternal11audioIOProcEjPK14AudioTimeStampPK15AudioBufferListS4_PS5_S4_Pv + 19
12 CoreAudio 0x00007fff354b4825 _ZN19HALC_ProxyIOContext10IOWorkLoopEv + 5021
13 CoreAudio 0x00007fff354b32bc _ZN19HALC_ProxyIOContext13IOThreadEntryEPv + 128
14 CoreAudio 0x00007fff354b2ffe _ZN13HALB_IOThread5EntryEPv + 72
15 libsystem_pthread.dylib 0x00007fff5dc5d661 _pthread_body + 340
16 libsystem_pthread.dylib 0x00007fff5dc5d50d _pthread_body + 0
17 libsystem_pthread.dylib 0x00007fff5dc5cbf9 thread_start + 13

[colin@loomer]

That may be a thing I've fixed in today's beta. Can you give 0.9.5 a try when I've uploaded it, and if the problem still exists, I'll delve deeper. Thanks.

[polarity-dnb]

yea, sure

[nordickvr]

Sorry Colin, but it seems like I missed something.
We'r going from 0.9.3 to 0.9.5, correct?

[colin@loomer]

Yes. 0.9.4 was an internal build that was sent to a few people to try and reproduce some issues. I thought it'd be confusing for them if there was another 0.9.4, so 0.9.5 it is.

I'll always put the builds and change-logs in the first post, so you'll know if you miss anything.