Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

adjustments for new hvcc #100

Open
wants to merge 12 commits into
base: develop
Choose a base branch
from

Conversation

dromer
Copy link

@dromer dromer commented Jul 24, 2021

Seems to work for me with these changes (and you can now drop python2.7 requirements).
I am probably missing some things since this entire process seems quite involved.
(my editor also removed trailing white-space in the README btw)

What I did to test this:

  • install emsdk and source emsdk_env.sh in the current shell (for emcc requirement)
  • make libs
  • build FirmwareSender and put it in Tools/
  • make HEAVY=Lich_PD_template load

You are probably not ready to switch to this, but at least should give some hints on what changes are needed to transition.

@dromer
Copy link
Author

dromer commented Jul 24, 2021

Btw, looking at build_send_receive_constants.py I'm thinking we should include this into hvcc by adding owl as a generator target. Instead of using the plain c target and adding this separately.

What do you think?

@pingdynasty
Copy link
Collaborator

I'm getting some merge conflicts, can you please rebase this against the current develop branch?

I think merging / integrating can be done in steps:
First step would be to use your hvcc fork, with minimal changes on our side.
Second step could be to integrate some of our modifications back into hvcc, like you suggest with a custom target.

@dromer
Copy link
Author

dromer commented Jan 26, 2022

You are right, yesterday I started fresh from latest develop which has some differences.

Indeed basic step would be to just use the plain c output from my fork, which should be exactly the same.
On https://github.com/Wasted-Audio/hvcc/tree/feature/owl I'm doing the work to make an actual owl generator.

@dromer
Copy link
Author

dromer commented Jan 27, 2022

I've been able to build this simple patch using the mentioned feature/owl branch of my hvcc installed in the path (pip -e).

It flashed to my Lich and responds to usb-midi ;)

I tried a [r Button_1 @owl B1] but that didn't seem to respond yet. Everything should be there though. Will try some other patches later, any recommendations?

@pingdynasty
Copy link
Collaborator

How did you build that?

Using your branch, with this command:
make PATCHSOURCE=TestPatches/HeavyTest HEAVY=HeavyTest clean patch
I get

./Build/registerpatch.h:1:10: fatal error: HeavyOWL_owl.hpp: No such file or directory
    1 | #include "HeavyOWL_owl.hpp"
      |          ^~~~~~~~~~~~~~~~~~

I see a couple of problems with the heavy.mk makefile:

  • generated code is not moved from c directory, so compiler does not know where to find them
  • output filenames don't seem to match expectations

@pingdynasty
Copy link
Collaborator

@dromer this is a fairly complex patch: https://www.rebeltech.org/patch-library/patch/Fascination_I
but it uses the old way of assigning parameters by name

Here's one with @owl you could try:
https://www.rebeltech.org/patch-library/patch/5_oscillator

@dromer
Copy link
Author

dromer commented Jan 28, 2022

How did you build that?

Did you use my feature/owl branch? -> https://github.com/Wasted-Audio/hvcc/blob/feature/owl/

I see a couple of problems with the heavy.mk makefile:

* generated code is not moved from `c` directory, so compiler does not know where to find them

The code isn't put in the c directory, see my changes. The new OWL generator makes the necessary mods to the bare c output and puts it directly in Source/ -> https://github.com/Wasted-Audio/hvcc/blob/feature/owl/hvcc/__init__.py#L319

* output filenames don't seem to match expectations

I've also changed the output filename set in Makefile.

@dromer
Copy link
Author

dromer commented Jan 28, 2022

multisaw75 builds fine here, only couple warnings:

OwlProgram$ make HEAVY=multisaw75 load
Building patch multisaw75
./Build/Source/Heavy_owl.hpp:58:7: warning: type 'struct Heavy_owl' violates the C++ One Definition Rule [-Wodr]
   int getNumOutputChannels() override { return 2; }
       ^
./Build/Source/Heavy_owl.hpp:50:7: note: a different type is defined in another translation unit
 class Heavy_owl : public HeavyContext {
       ^
./Build/Source/Heavy_owl.hpp:327:15: note: the first difference of corresponding definitions is field 'sRPole_KVbEacKy'
   ControlVar cVar_e3NB0O09;
               ^
./Build/Source/Heavy_owl.hpp:224:16: note: a field with different name is defined in another translation unit
   SignalSample sSample_77YiVojP;
                ^
./Build/Source/Heavy_owl.hpp:61:3: warning: '__ct_comp ' violates the C++ One Definition Rule  [-Wodr]
   int processInline(float *inputBuffers, float *outputBuffer, int n) override;
   ^
./Build/Source/Heavy_owl.cpp:64:1: note: return value type mismatch
 Heavy_owl::Heavy_owl(double sampleRate, int poolKb, int inQueueKb, int outQueueKb)
 ^
./Build/Source/Heavy_owl.hpp:50:7: note: type 'struct Heavy_owl' itself violates the C++ One Definition Rule
 class Heavy_owl : public HeavyContext {
       ^
./Build/Source/Heavy_owl.hpp:58:7: note: the incompatible type is defined here
   int getNumOutputChannels() override { return 2; }
       ^
./Build/Source/Heavy_owl.cpp:64:1: note: '__ct_comp ' was previously declared here
 Heavy_owl::Heavy_owl(double sampleRate, int poolKb, int inQueueKb, int outQueueKb)
 ^
./Build/Source/Heavy_owl.cpp:64:1: note: code may be misoptimized unless -fno-strict-aliasing is used

For that other patch I need all the separate pd files in PatchSource/ folder?

@pingdynasty
Copy link
Collaborator

Did you use my feature/owl branch?

I installed hvcc with pip as you suggested elsewhere. How do I use this branch instead?

only couple warnings

Looks like you need to add make target clean before load

For that other patch I need all the separate pd files in PatchSource/ folder?

Yes or you can put them in any folder and specify it with the PATCHSOURCE=... make argument.

@dromer
Copy link
Author

dromer commented Jan 28, 2022

Hah, yeah this is still on a feature branch, not released yet.

What I always do is:

git clone https://github.com/Wasted-Audio/hvcc.git
cd hvcc
git checkout feature/owl
pip install -e .

This way you can make edits to the code while it's installed in the path. Keeps the edit/test cycle small.

@dromer
Copy link
Author

dromer commented Feb 5, 2022

Btw, I've decided that we will start using @raw over the current @owl in send/recv objects

  1. more neutral name
  2. it is a kind of "raw" access to message objects
  3. it is useful for other generators (DPF cv-ports and VCV-Rack modules come to mind)
  4. it is also 3 letters and has a w in it

My branch has full backwards compatible use of @owl however the plan is to then phase this out in some future release. Use of @raw would be recommended. (need to add a warning or notification of some sort for this)

@dromer
Copy link
Author

dromer commented Feb 24, 2022

Until this is merged in a release of hvcc I suppose these tests will fail. Will see if I can make a version that installs from git directly until then.

@dromer
Copy link
Author

dromer commented Mar 17, 2023

Hmm, one thing I don't really understand is how to support the old naming convention like Channel-A, since receivers are actually not allowed to use - in the name:
https://github.com/pingdynasty/hvcc/blob/master/core/hv2ir/HIrReceive.py#L28
https://github.com/Wasted-Audio/hvcc/blob/develop/hvcc/core/hv2ir/HIrReceive.py#L41

@dromer
Copy link
Author

dromer commented Mar 20, 2023

compile-heavy.sh should probably just be removed. What is actually using this script?

@antisvin
Copy link
Collaborator

It's used by the web server when building patches. I don't think it belong to HVCC repo though. There's a relevant issue here: RebelTechnology/OwlServer#245

@dromer
Copy link
Author

dromer commented Mar 21, 2023

Ah, in that case it'll need some rewriting to work with the new HVCC. However I guess the web server still expects to be able to build several targets that are now much different.

Needs input from @pingdynasty to rewrite proper then.

For one, we have deprecated the internal bela target, as downstream bela actually uses the bare c target with their own wrapper. Also instead of the old vst2 that requires vst2sdk we now use DPF (which also includes vst3, lv2 and clap targets).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants