Major Changes - Githubissues

beserge commented 4 years ago

Done: Integrates with Heavy controls automatically for pod.

Todo: Automatically make and flash board. Support controls for patch. More cleanups for script and generated CPP for seed. Documentation explaining parameter names for different boards, how to modify cpp to communicate with PD patch, etc.

stephenhensley commented 4 years ago

Alright, a few notes on various things.

Also, I pushed a manually edited change to the pod_test example, and reorganized some of the stuff related to the notes below. But I wanted to document everything as I went.

Folder Structure

I'd like to keep the root directory as clean as possibly. It should really be made up of very few file things:

hvcc (submodule)
libdaisy (submodule)
util (static files necessary to generate project)
- daisy_boards.h
- Makefile
- template.cpp
examples
- pod_test/
- patch_test/
- etc.
pd2dsy.py

Project structure

I'd like to leave the hvcc files as separate as possible. Right now the generated source and Makefile are being placed inside the hvcc output.

Ideally a project would look something like this:

Project/
- Project.cpp
- Makefile
- daisy_boards.h
- c/
- hv/
- ir/

This makes it a little more friendly for users to come in and edit the file if they want, and to be able to see the distinction between the generated project file and the hvcc output.

Makefile

A simpler approach to the makefile will work, and only requires a single line to be generated by pd2dsy. Here's an example of a functional Makefile for the proposed project structure above.

Note that this requires #include "Heavy_pod_test.hpp" be changed to #include "c/Heavy_pod_test.hpp"

# Project Name
TARGET = pod_test

# Library Locations
LIBDAISY_DIR = ../../libdaisy
HVCC_DIR = c

# HVCC Sources
CPP_SOURCES = $(wildcard $(HVCC_DIR)/*.cpp)
C_INCLUDES = -I$(HVCC_DIR)/
C_SOURCES = $(wildcard $(HVCC_DIR)/*.c)

# Project Source
CPP_SOURCES += $(TARGET).cpp 

# Core location, and generic makefile.
SYSTEM_FILES_DIR = $(LIBDAISY_DIR)/core
include $(SYSTEM_FILES_DIR)/Makefile

Parameters

So far everything's pretty simple, and pretty solid.

I like the general idea of the parameter handling, as it exists.

We will have to figure out some way of being able to have/generate all of the params for each board, but focusing on the pod is fine for now.

We should definitely have an ENUM for mode instead of just numbers (it makes reading the static config a bit difficult).

We should consider replacing the Enc, Sw, AnalogControl*, etc. pointers with a void pointer that could be any of the following types. Something looking like:

struct DaisyHvParam
{
    enum ControlType
    {
        ENCODER_SW,
        ENCODER_INC,
        SWITCH,
        KNOB,
    };
    std::string name;
    void* control_object;
    ControlType mode;

    float Process()
    {
        if (control_object == nullptr)
            return 0.f;
        switch(mode)
        {
            case KNOB:
                return (AnalogControl*)control_object->Process();
            case ENCODER_SW:
                return (Encoder*)control_object->Process();
            default:
                return 0.f;
        }
    }
};

This would make the static init you're doing more like:

DaisyHvParam DaisyParameters[] = {
    {"Encoder", &boardsHardware.encoder, false, ENCODER__INC},
};

Which I think at some point we can wrap up into a template class that can build the DaisyHvParams for each breakout board.

Other

I think I originally had BEGIN and END sections for each code generation section. I noticed these are gone.

since we're just overwriting a template for now it doesn't really matter, but at some point we may want to be able to support regenerating the code of an existing project without clearing out any changes written in by the user. This is where having begin/end sections works well, because it signals the user to not write code in those sections, but can also be used to make sure that everything outside of those sections are preserved during a regeneration.

The generateCpp function is going to end up being realllyyyy long and really chaotic with all of the board specific stuff that's happening. This might be a good use for making a Board class that has functions for returning each section of code, the Board base class can have default stuff, or even the generic Seed replacements, and then you can make subclasses for each breakout board to change only what you need to change for specific boards. I think long term this will help clean things up a bit, and make it easier to add more breakout boards in the future without having to jump into the middle of a lot of code.

When we do get to adding a Parameter Manager of some sort we should wrap in default mappings for the OWL Pedal's generic parameters (Channel-A-E, etc. I believe -- not sure how that works out when it gets to hvcc, though).

Next step

lets get this PR to the point where the directory matches the layout mentioned above. (most of the way there with what I just pushed)
lets get the generation creating projects with the structure like what's now in pod_test, etc.
Add README to each example with what it does, how it works, how to create it (i.e. python pd2dsy --board pod pod_test.pd) and what (if any) manual adjustments were needed to get it to work after running pd2dsy.

From there I think this will be merge-able. The parameter rework, and simplification can be done in a separate PR afterwards.

Overall, great work so far. This is definitely shaping up.