Which repository directories are current?

OWL
#1

Hi all! I just got a Wizard and have been loving it so far. Already made progress on some C++ patches and I may put up a basic tutorial of some kind if that might be helpful.

I’m going to have lots of specific questions soon, but here’s a general one, based on picking through the repos. Between OpenWare and OwlProgram, which of the code related to patches is current? In particular, I see:

/OpenWare/LibSource (just a few files, including a non-deprecated version of StompBox.h)

/OpenWare/Source (lots of hardware files, including versions of ProgramVector with constants for current products [Wizard, Magus, etc.])

/OwlProgram/LibSource (what seems to be the most complete collection of patch-related files, including a deprecated version of StompBox.h)

/OwlProgram/Source (a little bit of hardware stuff, including a single, apparently outdated ProgramVector which doesn’t have constants for new products)

I think what’s throwing me is that LibSource seems more current in OwlProgram but Source seems more current in OpenWare, and yet both are in both with some overlap…

Many thanks in advance for your help, and congrats on making such a phenomenal product!

1 Like
#2

I’ve gone through this a bit more and it looks as though /OwlProgram/LibSource is where the dynamic components (Patch and supporting libraries) are being currently developed and /OpenWare/Source is where the static components (starting with Owl.cpp and its implementation of setup() and loop(), as called by the main.c files defined in the various hardware directories) are being developed. If that’s right, no need to explain! :slight_smile:

1 Like
#3

Yes that’s pretty much it!

It’s all a bit of a mess with tons of overlap because

  • OwlProgram, which is all about the dynamic patch, developed from the old firmware, and;
  • OpenWare supported statically compiled patches, but this part hasn’t evolved in time with OwlProgram

Going forward I think we’ll just remove LibSource from the firmware. For situations where you really want to compile a patch into the firmware (e.g. to make full use of all available RAM and FLASH memory) we can perhaps create a separate branch.

Oh and the go-to file for the Patch API is now Patch.h!

#4

Thanks very much for your reply. Makes good sense, and the context is helpful. Given the number of physical products and the complexity of the domain, I think it’s actually quite a well organized codebase!

I think I wrapped my head around (most of) the execution model this weekend. Would it be helpful if I wrote up a little doc about it based on my working notes and posted it on the forum? Others might be interested and it could save them some time exploring the repos.

I would only want to do this if you or someone at RT were able to check it for correctness first (no documentation is better than incorrect documentation…)

3 Likes
#5

hi @gc3,

I think there are a few of us here that are working with the open source firmware and dynamic patch library source for one reason or the other. I for my part think it would be great to start with some documentation of the firmware. It could make sense to review and evolve this documentation in a “rolling” fashion as we go within the community. That way the us users could help out RT with getting a hold on this, which is probably not uppermost on their agenda. Maybe we could open a specific tag/section of the forum to discuss and review these matters? What do you think?

Cheers,
Ben

EDIT: the more i think about this the better i think the idea is. A platform to involve the users interested in discussing code specifics would really be great and probably help to get answers more quickly if you need them without them getting lost somewhere. also a great way to teach yourself coding for embedded targets like the ones used for RT products.

1 Like
#6

Hi Ben,

I think that’s a fantastic idea and would be happy to pitch in! I am not planning on doing much firmware modification/recompiling any time soon, but understanding the firmware also helps clarify the execution environment for the Patch API (and is independently interesting).

A tag would be one way; if RT wanted to spin up a new version of the old Hoxton OWL wiki that might also work.

Starting proposal: why don’t I write up a (short, draft) overview of the repos, with a focus on the Wizard (which I have) and the Alchemist (which I don’t, but whose #ifdefs land very close to the Wizard). If you, @mars, and anyone else wants to check it for correctness and completeness, that’d be great.

My sense is that we should hold off on talking about the Magus until it’s officially released. Not only is the firmware not even in V1, but its parameter model is different enough from the others (passing everything through the Graphics class) that I would probably need to have a reference unit before I was confident saying much about it).

@mars, do you think that some user-contributed docs would be a net benefit to the project? I think we could do some useful work that would stay (mostly) out of your hair as you finalize and build the Magi. It might help new users get up and patching more quickly as the userbase grows.

Best,
gc3

1 Like
#7

Hey @gc3 ,

Couldn’t agree more :slight_smile:

Sounds like a plan, a wiki would be even better than a forum of course. @mars, how do you feel about converting the hoxtonowl website into a community DIY platform with documentation / tutorials around coding for Open Ware Lab (Patch API), the OwlWare and OpenWare firmware code bases? With a little TLC hoxtonowl could grow into a nice little knowledge base over time and hopefully be kept up to date.

Makes sense. I have the Wizard and the Owl Modular, which is why I’d also vote for adding documentation for OwlWare (“legacy” Firmware base).

Really looking forward to this!

Later,
Ben

2 Likes