Aunty Langton's Musical Ant needs YOUR help!

I didn’t run it (is there a patch so we can try it?) but from skimming the code quickly I’m pretty dubious that at this line

You really want std::numeric_limits::max() which is “the largest int there is” or (on your mac) 2^31 or so. What are you trying to accomplish with that comparison? Seems index will increase without bound basically (although i didn’t trace every use of it it does seem that it is mostly modded)

why all of the dynamic casts all over the place? that’s a big red flag for me - I’d look at your widget code if I were you.

Great, thanks for the input @baconpaul.

To be honest, this index value was needed in previous versions when looping functionality was not stateless but I reckon I can probably get rid of it now. Will have a crack at that shortly.

Hi @jerrysv, Okay, another area for me to focus on. I’ll get rid of them and use conversion methods if absolutely necessary.

As to the “why?”. I learned C at uni and that must have been what I was taught for that. Outdated syntax for C++ I see…

Cheers.

given that you’re on a Mac, you can compile with -g and run it with a debugger (lldb ./Rack)

configParam(MusicalAnt::CLOCK_PARAM, ...);

Should be

configParam(CLOCK_PARAM, ...);

shouldn’t matter … the enum is simply a number, not a memory reference.

editing to add that my count shows 21 parameters being defined with configParam and 24 being instantiated with createParam though, so there’s a problem there.

3 Likes

5+ replies under an hour! :grinning::grinning::grinning:

What a community. I’m popping out to run some life errands but look forward to trying some of these suggestions asap.

void process(const ProcessArgs &args) override {
    ...	
}

There is

void process(const ProcessArgs &args) override;

and

void MusicalAnt::process(const ProcessArgs &args) {
	
	
}

Possibly another minor observation.

Don’t think you need this line.

void draw(NVGcontext *vg) override {...};

should be

void draw(const DrawArgs &whatever) override {
    //then e.g.
    nvgBeginPath(whatever.vg);
};

I’m not too sure but I think the call for random::uniform() is changed?!

A quick report to let you know that I’ve built and run your module on Linux. I haven’t got much from it yet, I just started working with it, so I’ll use github to let you know of any issues. I look forward to seeing/hearing what you come up with. :slight_smile: Anyway, here’s what I see in Rack v1.dev:

crashing in json stuff. Those are automatic deletions normally… It’s a pain, but I would build for address sanitizer (asan). It will find a memory allocation error very quickly.

Just ran it and couldn’t make it crash. But I do notice that changing the resolution gives me junk on the screen - is it possible something is wrong there?

also in dataFromJson you don’t check if lastAntPosJ is null before you get the array element from it. Could that perhaps blow you up?

But like I said from playing for 3 minutes I couldn’t make it crash.

The noise when changing resolution is expected for now. I might implement some sort of hilbert curve algorithm to get around this in future tho :slight_smile:

Thanks @Squinky . I’ll check that out. I’ve been struggling with getting debugging happening on my mac. Have attempted valgrind and gdb but no joy. (probably PEBCAK related)

I’ll try lldb ./Rack first as @jerrysv suggested (thanks Jerry) then will look into this address sanitiser stuff after that.

no, valgrind isn’t always macOS compatible (and even when you can find a build that “works”, it’s fickle, and not compatible with Catalina at all), and since you’re on a Mac, you should really be using the compiler and tools it comes with (clang/clang++/lldb) instead of gcc/g++/gdb, so don’t beat yourself up too much about those.

address/memory sanitizers work pretty well, and are a bit nicer to work with imho, but my gut tells me that your issue is going to be either configParam() or draw() like @Coirt suggested (I had missed that one on my quick glance through your code). fix those two, and chances are it will work. either way, I’d put $1 on widget related.

1 Like

Valgrind makes rack run too slow to be be useful. asan seemed quite ok. And found my bug immediately.

1 Like

Hmmm… I was able to add the -g flag into my plugin Makefile alright and test but as soon as I add -fsanitize=address I get:

Could not find module “MusicalAnt” of plugin "AuntyLangtons"

This is similar to another thread I’ve read in which running Rack in dev mode, ./Rack -d changes the default plugins path…

That said, all of the vcvrack.com installed plugins on my Rack account are visible in the plugin library/picker… :thinking:

I don’t remember clearly, but I think you need to compile rack itself for asan. Anyone here remember?

1 Like