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

Using processor.frequency as buffer or vector size should be allowed but raises error #38

Open
DocSunset opened this issue Sep 18, 2020 · 2 comments

Comments

@DocSunset
Copy link

Using the soul command line version 0.9.53, the following minimum example fails to compile with the error:

example.soul:6:11: error: An array size must be a constant
    float[processor.frequency] buffer;

example.soul:

processor example  [[main]]
{
    input stream float audioIn;
    output stream float audioOut;

    float[processor.frequency] buffer; // <<< error occurs here

    void run()
    {
        loop
        {
            audioOut << audioIn;
            advance();
        }
    }
}

Since processor.frequency is described as a compile-time constant in the syntax guide (here), it seems like this should work.

Similarly, changing float[processor.frequency] buffer to float<processor.frequency> buffer also fails, with the error:

simple_delay.soul:6:10: error: Cannot resolve vector size expression in this context
    float<processor.frequency> buffer;

I suppose the sizes should technically be converted to int; doing so doesn't change the errors produced.

I would like to use this in order to have a buffer for delays with a maximum delay time specified (at compile time) in seconds. This requires the buffer size to be an expression using processor.frequency.

@julianstorer
Copy link
Contributor

Yep - absolutely, it should work, and one day we will make it work, but for enormously complicated reasons, it's a really really difficult one to fix.

We've had it on our to-do-list for ages, but... (deep breath...) processor constants are only known at a late stage in the compile process, so they get resolved in HEART code, not SOUL. You're trying to us this constant as part of a type, but the HEART type system is much simpler than the SOUL one, and it can only represent concrete types, not ones that contain unresolved constants.

So despite this seeming like a trivial problem, to get it working means probably about a month's work to completely re-implement the HEART type system (!)

@DocSunset
Copy link
Author

Thanks for the clear explanation.

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

No branches or pull requests

2 participants