Midihandler Code and HelpPatches

#1

Hi there. I'm new to the Axoloti, and have been trying to pick up the basics for coding my own objects. The Creating AXO Objects post (https://sebiik.github.io/community.axoloti.com.backup/t/creating-axo-objects/481) has been especially helpful, so many thanks to @alex for posting it!

However, for the life of me I can't find much documentation on what the point of the code.midihandler and helpPatch blocks in an object are, and how they work together with the other blocks. I've done a few forum searches here and haven't turned up much, but I feel like I must be missing something that's already on the forum. If that's the case, I'm more than happy to close/delete this post once I can find a link to those posts.

If that isn't the case, it'll probably help this post if I outline the assumptions I've been making, so we have something more concrete to start talking about.

For the code.midihandler block, I'm assuming you use it (1) to receive data from the midi in port and pass it onto your k-/s-rate code, and (2) to take data from your k-/s-rate code and send it to the midi out port. Is that on the right track? I've also poked around in some of the factory .axo files and the axoloti-runtime/firmware folder, and it looks like the midi_usb.c, midi_usb.h, midi.c, and midi.h files in the firmware folder hold some of the constants and functions that get used in the midihandler block. Is this right? And are there any other files that add more functionality to the midihandler block?

As for the helpPatch block, I'm assuming it gets used to include .axh files in your object, but beyond that I'm lost. I've poked around in some of the .axh files too, but haven't been able to wrap my head around what they are doing.

Any thoughts you could share with me would be a huge help.

#2

That sounds about right to me. I am hobby coder, but that is also my understanding of the object. Did you check any of the midi in and out objects? for example:
midi/in/keyb

They'll show you how its used.

I am not 100% sure what you mean by Helpblock? In "overview" of the object you can add your own helpfiles to objects.

But the help patches can be very useful. Some of them are pretty informative some less But also be aware that not all objects have helpfiles. But overall they are there to show usecases of objects.

But I'd say that objects are often also described pretty well in the object descriptions.

#3

@jaffasplaffa Thanks for the response. Glad to hear I'm on the right track with the midihandler block. After thinking about it a little more, I think the main question I have is when/where this code gets executed, especially in relation to the k-/s-rate code, but to answer that it's probably easiest for me to wire up a patch and look over the xpatch.cpp file that gets created.

As for what I mean by the helpPatch block of code, I'm going off of the .axo file skeleton from the 'Creating AXO Objects' post I linked to above. The 10th line there shows how you open/close a block of code with 'helpPatch' as the label between the angle brackets. (I'm probably still explaining this poorly, but if you follow the link you should be able to see what I'm talking about).

Based on what you've said about .axh files, it sounds like my assumptions about the the helpPatch block were backwards. I was assuming .axh files included some sort of functionality that .axo files could call on at some point during their execution, and therefore you would use the helpPatch block to list out .axh files similar to how you would use the includes block to list out .h files. But it sounds like .axh files are really just special .axp files that show a paradigm usage of a particular .axo file. Is that correct?

#4

Ahh yeah, NOW I get where you are coming from. Sorry I didnt check the link before answering.....

The page you are looking at is to be honest a bit outdated. By that I mean you really do not need to edit names, uuid, sha etc. in XML editor, cause there are other ways of doing it that works MUCH better and is much easier. But as said, the link is outdate, it is really not the way its done these day, as the editor has been updated and can do most of the stuff automatically.

The BEST way to create an Axo object is:
1. find the object you want to edit.
2. Push the triangle in the top corner of the object and select "embed as patch object"
3. Now you have your own object free of the com.lib., but you still need to SAVE the object as you own, which Ill get to next. When you push "edit" you will get access to the internal object editor, which i highly recommend using, its to me much easier than XML, but I guess it depends on ones coding skills).

Okay, so you need to save the object, which is next step. And i REALLY recommend you doing it this way instead of the "manual" way your were trying.

  1. Push "edit" on the object top open object editor, go to "file" and select "copy to library".
  2. Put in details of where you want to save, local or community..... and save it.
  3. Wait for the log to finish updating the library.
  4. Type in the object name in the object finder and watch your new object come up :slight_smile:

When you do it like this most things that HAVE to be done to an object, is done automatically, like creating those Id's, SHAA, UUID, etc that you can see in the link you posted.

Try this and see if it makes more sense to you :slight_smile: Yu should just get used to using the internal object editor instead its much easier and much faster overall.

(If you want to create a helpfile, you need to put the helpfile into the same folder as the object the helpfile belongs to. And then add it in the object editor in the "overview" menu. But check the other stuff first and then maybe wait with looking into the helpfile stuff)

#5

Yes this is misunderstanding. The helpfiles are really only there to show different use cases and for some of the more complicated objects its pretty nice being able to see how you set it up.

#6

Thanks for your help @jaffasplaffa! It gives me a better idea for the big picture.