Code Generation from Json and better build infrastructure #35

crop2000 · 2024-12-24T16:23:20Z

This pr grow out of the idea to have an enum to access parameters.
It also introduces a way to access the parameters via struct that mirrors the group structure.
In addition to this i also looked at the faust builder and introduce FaustArg enum to have a flexible basis to write builder functions.
I make use of the enum in faust-macro.
I also cleaned up my recent addition to the faust builder.
Changes to the builder should be backward compatible.
I use the builder in the exmple-f64.
I realized that the faust architecture file is not an ideal design pattern to interact with in a rust build script. In the example-f64 and faust-macro I show how one can create a architecture wrapper using quote.
i add a new jack example utilizing all the things i introduced.

examples/example-jack-new/build.rs

examples/example-jack-new/dsp/volume.dsp

faust-build/src/faust_arg.rs

obsoleszenz · 2025-03-24T00:45:11Z

So i looked into this a bit now and i feel like this is a really nice overhaul of rust-faust.
Following things i would like to see:

Instead of introducing example-foo-new, just update the old example. Your improvements should define the state of the art of creating rust-faust projects, no need to keep the old examples around
I would like to not manually call std::process::Command in the examples and instead use FaustBuild

In general this feels like we could bump the crate version to 1.0.0 with your changes, really powerful stuff!

crop2000 · 2025-03-25T22:45:03Z

I kind of would like to do the integration of the new example and the update of FaustBuild in a separate PR.
What I could do is to add some comments to the changed examples and describe what it exemplifies.

obsoleszenz · 2025-03-26T17:06:09Z

I kind of would like to do the integration of the new example and the update of FaustBuild in a separate PR. What I could do is to add some comments to the changed examples and describe what it exemplifies.

Hmm then i think we need to reiterate on how to merge this pr. Merging it like this makes the example situation quite confusing to new adopters and i would like to prevent that. Can we split this pr into smaller chunks that are more easy to merge?

I'm thinking of following:

Extend FaustBuilder to use FaustArg
Extend FaustBuilder with a method like this: fn use_architecture(self, architecture_fn: Fn() -> TokenStream) -> Self
And then in another pr work on faust_json for the codegen?

crop2000 · 2025-03-26T19:33:04Z

this pr now only contains the examples but we agreed that the examples should be reduced to best practices

obsoleszenz · 2025-04-02T13:19:47Z

examples/file-f64/build.rs

+    b.set_xml();
+    b.set_code_option(CodeOption::Double);
+    b.set_architecture(Architecture::Object(Box::new(ArchitectureUI {})));
+    b.build();


I feel file-64 is a bad example name. How about volume-f64 ?

the example is about using files and f64 ... it is not important that it contains a volume dsp. this is the naming convention used for all the examples

obsoleszenz · 2025-04-02T13:22:08Z

faust-json/src/enum_interface.rs

+pub fn create(dsp_json: &FaustJson, dsp_name: &Ident) -> (TokenStream, bool, bool) {
+    let param_info = dsp_json.get_param_info();
+    create_from_paraminfo(&param_info, dsp_name)
+}


I think the codegen should be a seperate crate, as i feel this is quite opinionated. Also I would prefer having the ui types/traits not bleed into faust-types. Also i propose renaming faust-json to faust-ui-description-json or maybe even merging faust-xml and faust-json under faust-ui-description.

What do you worry about when the traits for ui are in the faust-types

obsoleszenz · 2025-04-02T13:22:37Z

faust-types/src/lib.rs

+    type F;
+    fn get_value(&self, dsp: &D) -> Self::F;
+    fn get_enum(&self, dsp: &D) -> Self::E;
+}


As stated above, I would prefer having the ui types/traits not bleed into faust-types but be in faust-ui-codegen or something similar.

what do you worry about when there are more types intoduced and included together? they don't need to be implemented.

obsoleszenz · 2025-04-02T13:24:37Z

faust-build/src/builder.rs

+        self.compile_options.xml = true;
+    }
+
+    pub fn set_json(&mut self) {


Suggested change

pub fn set_json(&mut self) {

pub fn write_ui_description_json(&mut self) {

In the current version i choose a different name

faust-build/src/builder.rs

obsoleszenz · 2025-04-02T13:29:39Z

faust-build/src/lib.rs

+pub mod option_map;
+
+pub trait ArchitectureInterface {
+    fn wrap(&self, builder: &FaustBuilder, dsp_code: TokenStream) -> TokenStream;


Suggested change

fn wrap(&self, builder: &FaustBuilder, dsp_code: TokenStream) -> TokenStream;

fn architecture(&self, builder: &FaustBuilder, dsp_code: TokenStream) -> TokenStream;

the idea to call this function wrap is because this is what you do. you use the architecture object. and wrap it around the generated code.

obsoleszenz · 2025-04-02T13:30:01Z

faust-build/src/lib.rs

+pub mod macro_lib;
+pub mod option_map;
+
+pub trait ArchitectureInterface {


Maybe

Suggested change

pub trait ArchitectureInterface {

pub trait ArchitectureCodeGenerate {

maybe just Architecture? ok thats in use already. but i feel ArchitectureCodeGenerate is a bit long. ... i realize one problem the two example instances ArchitectureDefault ArchitectureUI could both be implemented as a function.

So basically the ArchitectureCodeGenerateObjectInterface 😅 doesn't even have a use case yet.

faust-build/src/builder.rs

obsoleszenz · 2025-04-02T13:34:26Z

faust-build/src/builder.rs

+pub enum Architecture {
+    None,
+    Function(bool), //todo
+    Object(Box<dyn ArchitectureInterface>),


Suggested change

Object(Box<dyn ArchitectureInterface>),

CodeGeneration(Box<dyn ArchitectureCodeGeneration>),

I think when you look how the code is used in builder and the examples you can see how the naming convention is working.

obsoleszenz · 2025-04-02T13:37:17Z

faust-build/src/builder.rs

+            #ui_reexport
+        }
+    }
+}


Can you also move this to the seperate ui codegen crate?

I think you refer to the function that opens the json file and calls generate_ui_code i leave it in the builder because the builder takes care of files whereas faust-ui doesn't.

obsoleszenz · 2025-04-02T13:45:37Z

faust-build/src/code_option.rs

+
+#[derive(Debug, Clone, Eq, EnumDiscriminants, EnumIs, EnumString)]
+#[strum_discriminants(derive(Hash))]
+pub enum CodeOption {


Suggested change

pub enum CodeOption {

pub enum CodeGenerationOption {

To stay in line with the faust naming

A bit unfortunate that we will have FaustCodeGeneration and ArchitectureCodeGeneration, but well, i think we can explain the difference with good documentation.

I don't see the point for a longer name

CodeOption is not a descriptive name. At least call it CodeGeneration.

But those are not generating anything they are just options, flags or...?

How about CodeFlag?
I think this is clear enough in the context of the faust-builder

But they are about the CodeGeneration, if we map something to a portion of the faust args, we should call it the same way and not introduce new/different/incomplete naming. And the faust cli clearly calls it Code generation options. Not flags. But we can rename those things later too, but those things should be settled when we cut a release so that we don't introduce breaking changes.

obsoleszenz · 2025-04-05T13:06:32Z

examples/minimal/build.rs

+fn main() {
+    println!("cargo:rerun-if-changed=dsp");
+    let mut b = FaustBuilder::default_for_file("dsp/volume.dsp", "src/dsp.rs");
+    b.set_architecture(Architecture::default());


Isn't the default architecture set by default_for_file?

currently the default_for_file sets as little as possible so it does set Architecture to None which currently applies default

rust-faust/faust-build/src/architecture.rs

Line 46 in dbe6ded

default(builder, &ts)

... not sure if this is the best idea.

faust-ui/src/struct_interface.rs

obsoleszenz · 2025-04-05T13:13:48Z

faust-build/src/architecture.rs

+pub enum Architecture {
+    None,
+    Function(&'static dyn Fn(&FaustBuilder, &TokenStream) -> TokenStream),
+    Object(Box<dyn ObjectInterface>),


What's the benefit of Object over Function?

An object could carry other information that is needed when apply() is called. For example one could prepare another string or file name that is used for generating the wrapping content. An example for that would we module name. If it would not be provided by the builder.

obsoleszenz · 2025-04-05T13:30:24Z

examples/file-f64/src/dsp.rs

+        }
+    }
+}
+pub static DSP_UI: DspUiVolume = DspUiVolume::static_ui();


What is the differentiation between Active & Passive?
Is Active Read + Write and Passive only Read?

Active are sliders and one should set the value. i think one should not design ones programs to also read them. Passive are meters and one should read the value.

Active are sliders and one should set the value. i think one should not design ones programs to also read them. Passive are meters and one should read the value.

Why should one not read them?

i mean one should not depend on reading the slider values from the dsp struct because one anyway need to send them there from another context.

refactor faust-macro: refactor to make use of ui generated from json make use of architecture functions by default refactor faust-build rewrite examples make more use of clippy lints remove default private module around dsp code and create a public module if apropriate ... some code cleanup is possible because of this

…rn without reexports

…compatibility

crop2000 force-pushed the macro_extensions branch from a37297a to a22cf0e Compare December 28, 2024 05:45

crop2000 force-pushed the macro_extensions branch from 24781fe to 56e64c9 Compare January 17, 2025 13:14

obsoleszenz reviewed Mar 24, 2025

View reviewed changes

examples/example-jack-new/build.rs Outdated Show resolved Hide resolved

obsoleszenz reviewed Mar 24, 2025

View reviewed changes

examples/example-jack-new/build.rs Outdated Show resolved Hide resolved

obsoleszenz reviewed Mar 24, 2025

View reviewed changes

examples/example-jack-new/dsp/volume.dsp Outdated Show resolved Hide resolved

obsoleszenz reviewed Mar 24, 2025

View reviewed changes

faust-build/src/faust_arg.rs Outdated Show resolved Hide resolved

crop2000 force-pushed the macro_extensions branch from 56e64c9 to a4be3f8 Compare March 26, 2025 18:26

crop2000 mentioned this pull request Mar 26, 2025

2: Cleanups #37

Merged

crop2000 force-pushed the macro_extensions branch 3 times, most recently from a416f9a to 547223f Compare March 26, 2025 19:20

crop2000 marked this pull request as draft March 26, 2025 19:31

crop2000 force-pushed the macro_extensions branch 3 times, most recently from 79552d9 to 2bc46b7 Compare April 1, 2025 09:35

obsoleszenz reviewed Apr 2, 2025

View reviewed changes

faust-build/src/builder.rs Outdated Show resolved Hide resolved

obsoleszenz reviewed Apr 2, 2025

View reviewed changes

faust-build/src/builder.rs Outdated Show resolved Hide resolved

obsoleszenz reviewed Apr 2, 2025

View reviewed changes

crop2000 force-pushed the macro_extensions branch 3 times, most recently from e28f3b0 to 8e9de13 Compare April 3, 2025 13:04

obsoleszenz reviewed Apr 5, 2025

View reviewed changes

faust-ui/src/struct_interface.rs Outdated Show resolved Hide resolved

obsoleszenz reviewed Apr 5, 2025

View reviewed changes

crop2000 marked this pull request as ready for review April 5, 2025 22:35

crop2000 force-pushed the macro_extensions branch from fedd83b to afb8d28 Compare April 6, 2025 15:40

crop2000 force-pushed the macro_extensions branch from afb8d28 to 7d3b14b Compare April 7, 2025 09:56

crop2000 added 2 commits April 7, 2025 15:28

change template file back to having a module follow the current patte…

3cb5235

…rn without reexports

provide <<moduleName>> for template file again to increase backwards …

7e80c7a

…compatibility

obsoleszenz merged commit c720d04 into Frando:main Apr 8, 2025

	pub fn set_json(&mut self) {
	pub fn write_ui_description_json(&mut self) {

	fn wrap(&self, builder: &FaustBuilder, dsp_code: TokenStream) -> TokenStream;
	fn architecture(&self, builder: &FaustBuilder, dsp_code: TokenStream) -> TokenStream;

	pub trait ArchitectureInterface {
	pub trait ArchitectureCodeGenerate {

	Object(Box<dyn ArchitectureInterface>),
	CodeGeneration(Box<dyn ArchitectureCodeGeneration>),

Code Generation from Json and better build infrastructure #35

Code Generation from Json and better build infrastructure #35

Conversation

crop2000 commented Dec 24, 2024 • edited Loading

obsoleszenz commented Mar 24, 2025 • edited Loading

crop2000 commented Mar 25, 2025

obsoleszenz commented Mar 26, 2025

crop2000 commented Mar 26, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

obsoleszenz Apr 2, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

obsoleszenz Apr 2, 2025 • edited Loading

Choose a reason for hiding this comment

crop2000 Apr 2, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

obsoleszenz Apr 2, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

obsoleszenz Apr 2, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

obsoleszenz Apr 6, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

crop2000 Apr 5, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

crop2000 Apr 5, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

crop2000 commented Dec 24, 2024 •

edited

Loading

obsoleszenz commented Mar 24, 2025 •

edited

Loading

obsoleszenz Apr 2, 2025 •

edited

Loading

obsoleszenz Apr 2, 2025 •

edited

Loading

crop2000 Apr 2, 2025 •

edited

Loading

obsoleszenz Apr 2, 2025 •

edited

Loading

obsoleszenz Apr 2, 2025 •

edited

Loading

obsoleszenz Apr 6, 2025 •

edited

Loading

crop2000 Apr 5, 2025 •

edited

Loading

crop2000 Apr 5, 2025 •

edited

Loading