Has anyone else had the Barlow Arpreggiator go into bypass mode after a few measures ? Usually the third measure after the start, then it may or may not go into bypass if manually corrected while playing.
I have had this happen on multiple Ardour sessions and in Mixbus 9.2 latest as well. Windows 10 and Linux version downloaded from here.
Lua DSP scripts are disabled (bypassed) when they encounter an exception.
Do you have tempo-ramps in the session?
If so that could explain things. The Barlow Arp has the following comment, and the assert() may trigger:
-- next beat is due some time in this cycle (we're assuming constant
-- tempo here, hence this number may be off in case the tempo is
-- changing very quickly during the cycle -- so don't do that)
local d = math.ceil((b2-bf2)/(b2-b1)*(s2-s1))
assert(d > 0)
Thank you for the response.
There are no tempo-maps in the session.
What is odd is that if the song is played from the beginning, Barlow bypasses on the start of the 3rd measure every time. If the song playback is started on the second measure, it will not bypass when it gets to the third measure, and seems to randomly bypass somewhere else. Maybe it is operator error with an edit gone bad somehow. I don’t know yet.
I have had something similar happen in multiple sessions. I am unable to reproduce it. It happens when I am doing a lot of MIDI type work. All drag and drop with Free MIDI Chords, maybe an occasional layer, and then combine. With the limited edit functions that I am doing on the MIDI region, there should be no timing issues. I will see if I can reproduce the issue repeatedly and go from there. If it is not operator error, it may be snap, combine, or layering causing something to throw off the timing. I would think that by using snap, I would have avoided any timing errors in general.
Is there anything in Window > Log? There should be a “LuaException:” warning.
@aggraef any ideas?
Hmm, there could be other places where the script runs into an exception, maybe a table index out of bounds, division by zero or something like that. I’ve used Raptor quite heavily and haven’t run into any exceptions so far, but that doesn’t mean that there couldn’t be a rarely executed code path which I haven tested yet.
@Schmitty2005 If you have a smallish session which lets me reproduce the issue then I’ll look into it.
And yes, any related Log message would be helpful, too. If I know where in the script it dies then I can try to figure out what’s going on there.
Nothing in the Log window on Windows 10. I tested the same faulty Win10 session with Linux and there was no problem. It work flawlessly.
I have added this issue to the tracker :
https://tracker.ardour.org/view.php?id=9541
Here are some other WIN10 only problems with debug logs. Maybe there is something useful in those as to why the Win10 builds seem error prone?
Win10 Issue with debug logs
Thank you. I have attached a small session to the tracker log. At this point, I am only able to reproduce this in Win10. The same session that was giving fault in Win10 worked flawlessly in linux!
When/If I have this happen in linux, I will add that session to the tracker.
The tracker link is in the post to x42 if you are interested.
That is strange. There is nothing OS specific regarding Lua scripts (or Ardour in general).
Yes. I have used Ardour in Linux for hours and left it running for days with no issues. When I use Win10, there are random anomalies with Ardour that I am unable to reproduce. If I use Ardour or Mixbus for an hour or two, I am sure to run into a problem. Other software works fine with no issues whatsoever. I have used Cubase 12 for days without a hitch. There are no hardware issues that I am aware of ( SSD, Mem, Bios) Intel i7 4500 w Intel Chipset.
I see that you tried the copy and rapid paste MIDI. It worked fine on your Win7. Thank you for trying that. That helps to realize it may be my system.
Are there any runtime dependencies in Windows that Ardour relies on that I could check into ? Come to think of it, I installed a GTK runtime for windows several years ago. It is probably still hanging out on the system. Maybe it is causing some sort of ruckus. I will remove it and see what happens.
On Win10, when I have several tracks. I get a graphical ripping of the graphics when using the slider at the bottom, as though the computer cannot drawn the GUI fast enough to keep up. In linux, there is no such issue. It is smooth and responsive. Is that a normal Windows type issue with Ardour ? Is GTK is not able to refresh at full speed or have trouble on Windows ?
Weird. Unfortunately, if the issue is Windows-specific, that makes it much harder to find the root cause of the problem, since any number of OS- and machine-specific characteristics come in, such as potential hardware and/or driver issues.
I’ve used Raptor extensively on both Linux and Mac, but I have to admit that I didn’t do much testing on Windows, just tested it with a few simple sessions. So there might still be some gremlins there, but they’re more likely to be in Ardour rather than the Lua interface or Raptor itself which are both OS-agnostic.
@Schmitty2005 One thing you could check is whether the problem persists if you replace Raptor with the Barlow arpeggiator. If the problem persists, that would imply an issue with the beat detection logic which is basically the same in both plugins. If it goes away, that would point to an issue with Raptor’s internal data structure and algorithm, which are much more complicated than in the other arpeggiators.
Also, I remember an issue early on with Raptor going bonkers if automation was used. But that has since been ironed out by ensuring that regular_block_length = true is set on the plugin. Still it might be worth checking whether removing any existing automation on the track with Raptor has an impact on the problem.
I’ve looked at that assert(d > 0), and I don’t see how it could be tripped, ever. If time would suddenly run backwards for some reason, that would be caught by the bf2 > bf1 condition (which implies b2 > b1). That code path then wouldn’t be executed at all.
The only potential issue I see there is if the sample counter goes haywire so that time.sample >= time.sample_end which, if I understand it correctly, should be guaranteed to never happen by the Lua interface. I have not looked at the C/C++ code which sets up the time Lua table in the interface, though. @x42 Maybe you could have another look at that?
Ok. Thank you for the explanation. In my faulty session, I replaced Barlow with Raptor. I adjusted the settings to be the same the best that I could. They do not product the same output; but that is not a big deal, I don’t understand some of the settings yet.
Overall, I could not get Raptor to reproduce this error. It worked flawless. After tinkering around with Barlow and Raptor, I tried Barlow again, now it goes into bypass everytime it gets to the second measure, but only when the song is started from the beginning, instead of the 6th like it did time after time before trying raptor and tinkering. And then back to Raptor, it worked like it should, but I could never get settings that replicated the Barlow for exact testing purposes.
At this point, if others are not having a problem, it may be something on my system. I do not know what. Everything else on Win10 is working fine.
By the way, thank you for Barlow and Raptor. They are above and beyond any arpregiator that I have tried! Very music orientated and adjustable.
@x42 @aggraef
I have isolated the problem. It is related to the ASIO audio drivers for the Native Instruments Audio Kontrol 1 in some way. When I use ASIO4ALL with the Audio Kontrol 1 , there is no issue with the Barlow going into bypass by itself.
It leaves me to think t that the remaining odd problems I am having with Ardour/Mixbus are somehow related to the ASIO Audio Kontrol 1 drivers and will test with that in mind.
Thank you both for your help on this.
Hmmm…I spoke too soon. There was a problem with Raptor going into bypass all by itself. Switching sound card drivers did not help fix it this time. It ONLY happened after I duplicated a track with Raptor, and then BOTH MIDI tracks would go into bypass and never allow themselves to be enabled.
I will see if I can find a method to repeatedly cause this issue.
The log was showing this error
2023-11-19T11:05:07 [INFO]: LuaProc: loop: playing bar 1/0
EDIT: Deleting and adding the Raptor fixes the issue.
2023-11-19T11:05:07 [INFO]: LuaProc: loop: playing bar 1/0
Hmm, yes, that seems to indicate that you accidentally toggled Raptor’s Loop button while no loop was recorded yet, and then Raptor goes into bypass, apparently due to an index out of bounds exception in a Lua table access. For once, I can reproduce this. 
And it’s most definitely a bug in Raptor, I can fix this.
The strange thing is that I don’t see the Lua exception, neither in the Log window, nor in the terminal output. @x42, shouldn’t those Lua exceptions be printed somewhere? Or do I need to invoke Ardour with some kind of debugging option to make that happen?
The interaction with the ASIO driver is weird. The only thing that I can imagine is that the driver might mess with Ardour’s block sizes. If that bug happens with the Barlow, but not the Raptor arp, then we might have to give the former the same treatment concerning the regular_block_length option.
@Schmitty2005 If you can find the barlow_arp.lua file somewhere in Ardour’s program directory (probably in the scripts subdirectory), then you can edit the file in order to change this line (at line 40 in the file, in the dsp_options function), which reads:
return { time_info = true }
Change that to:
return { time_info = true, regular_block_length = true }
You need to use a decent text editor for that, not Microsoft Notepad which messes up UTF-8 text files by putting a BOM at the start of the file. I’d suggest Notepad++ which is free (as in beer).
Save the file, relaunch Ardour, load your session, replace the Barlow plugin in the session, and see whether that fixes the issue with the Kontrol 1 driver.
@x42, I fixed the raptor_arp looper bug in raptor_arp: Fix looper bug reported in the Ardour forum by Schmitty2005. · agraef/ardour-lua@806e669 · GitHub. Maybe you could pull this over to the Ardour repo? Thanks.
@Schmitty2005 I also added a potential fix for your driver issue in Enable regular_block_length in all arpeggiators, to hopefully work ar… · agraef/ardour-lua@8e0b600 · GitHub. You can download the Barlow arp file here: https://github.com/agraef/ardour-lua/blob/main/dsp/barlow_arp.lua. Just replace the existing file with that one and please let me know whether that fixes your Windows Kontrol 1 driver issue.
Thanks, I just did that (8.1.113)
On windows that would be
C:\Program Files\Ardour8\share\ardour8\scripts\barlow_arp.lua
Thanks. Concerning the Lua exceptions missing in the log, maybe I misremembered that. I’m pretty sure that these will be printed for action scripts (in the Lua Scripting window), but maybe not for dsp scripts.
For debugging dsp scripts, it would be tremendously useful to have the Lua exceptions printed either in the log or on stderr, if that seems possible.