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

[cturner]

Glad I could help out!

[colin@loomer]

Glad I could help out!

It appears that Bitwig only updates the position in the transport information that's passed to plug-ins when its own transport is playing. This means that the issue that you are seeing is not the only case where this problem manifests: if you stop Bitwig and manually adjust the play position in Bitwig's transport display (the 1.1.1.0 as the top of the ui), Architect (or indeed any hosted plug-ins) will not get the updated position until your press play.

To say I'm no Bitwig Studio expert is an understatement, but I can't see any option to change the behaviour. If anyone knows any different, I'd appreciate it if they could chime in.

In the meantime, I'll contact the Bitwiggers directly and let them know about this. (It also appears that Bitwig is sending out the wrong MIDI clock signals for synchronisation, if I've interpreted the spec correctly. I am on an older Bitwig Studio build, though, so it may have been corrected in the interim...)

[cturner]

Well, not the best news, but great to have clarity. Thanks again, Colin!

[cturner]

Hi Colin- A question concerning [get clock]: when it's hooked up to [on every tick], does it begin at 0 or 1? Does it reflect elapsed ticks and so never outputs 0 as a value? Just 1 at the end of the first tick? Thanks.

[colin@loomer]

A question concerning [get clock]: when it's hooked up to [on every tick], does it begin at 0 or 1?

There is a 0th clock, which is the very start of the arrangement, equivalent to 1.1.001 in the transport. If you stop and rewind, the transport will rewind to this 0th clock position. Clock 1 will then be 1.1.002, etc. Clocks can also be negative if you put the transport to anything before 1.1.000.

[cturner]

Thanks Colin, very helpful. Really having some trouble reconciling an array of “ticks” to what the Bitwig transport and grid is sending out. Perhaps I should try another DAW.

:-/

[colin@loomer]

Thanks Colin, very helpful. Really having some trouble reconciling an array of “ticks” to what the Bitwig transport and grid is sending out. Perhaps I should try another DAW.

:-/

If you send me what you have - or just the timing component - then I can take a look and maybe see if it's either a Architect bug, a DAW timing quirk, or a bug in your patch?

I had to code quite a lot of fancy workarounds to deal with the fact that DAW timings can be quite unpredictable, so even if the bug does turn out to be DAW-based it may be something I can account for.

[cturner]

Thanks, but hahaha: It turned out to be an evaluation order problem. The MIDI was triggering the last (not current) clock tick held in [get element]. C'est la vie. Onwards!

[cturner]

Hi Colin- What do you think about the design of a preset that would benchmark Lua scripts in ticks? I have a vague thought that I could latch the current clock tick, invoke my Lua script, and on completion, again get the current tick, then subtract previous tick from current. Possible? Any caveats?

[colin@loomer]

Hi Colin- What do you think about the design of a preset that would benchmark Lua scripts in ticks? I have a vague thought that I could latch the current clock tick, invoke my Lua script, and on completion, again get the current tick, then subtract previous tick from current. Possible? Any caveats?

No need: Lua scripts (like all modules) always run to completion on the same tick. The only exception here is code that is either outside of a function, or in the `load` function. In both of those cases, that portion of the script is executed on a different thread, outside of the audio thread, and hence having no concept of ticks or clock position. Which makes it an ideal place to do CPU intensive stuff like generating look-up tables or such things.

[cturner]

Actually, I see two good ways to proceed with this.

If a Lua script completes in one tick, what happens in the admittedly cooky case of a Lua function with an infinite loop: while(1)? Does Architect terminate the process, or does it hang?

EDIT: I realize now your reference to "load" was to the arc method arc.module.load(), not the Lua load function.

I read pp. 71ff in Ierusalimschy’s “Programming in Lua”, but it seems that code needs to be executed after it’s loaded. So does that execution run outside the audio thread?

I actually doubt my code takes longer than 1ms to complete, but I do need to run it repeatedly while the preset executes, not just at setup time. Will Lua’s load() enable me to do that outside Architect’s main thread?!

[ThomasHelzle]

I can affirm that timeline behaviour in Bitwig. Current versions should be better in some regards (try the latest demo) but there is no concept of "scrubbing" or moving around the timeline while it's not playing. Has a big bit to do with it being non-linear, but part of it is that it's just not there, even in the arranger part.
At least double-clicking on the stop button and other such clear things should send a time/reset to all plugins though IMO, but don't...
It's often hard to actually reset things properly in Bitwig, sometimes you have to stop, hit play and stop again immediately to get the next best thing...

Cheers,

Tom

[cturner]

Thanks for that, Thomas!

[colin@loomer]

I see you've come up with another solution, cturner, but for your information: yes, Architect will terminate any Lua scripts that take too long.

[cturner]

Most interesting. Have a good week, Colin!