HISE Logo Forum
    • Categories
    • Register
    • Login

    DSP Development Pipeline

    Scheduled Pinned Locked Moved General Questions
    5 Posts 3 Posters 456 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • C
      clumsybear
      last edited by

      I was thinking about a development pipeline and wanted to check if this would be possible.

      Basically it's about extending HISE functionality.
      I have programmed some DSP algorithms in Gen~ which at the moment are quite tricky to realise solely in HISE. I also managed to export them via JUCE as audio plugins.
      The thing is, I really like to work within the HISE environment to do all the routing, mapping and audio design, especially since scriptnode showed up. Thanks for that @Christoph-Hart :)

      So how complex would it be to port the JUCE code I wrote to HISE and use these DSP effects as Scriptnode nodes for example?

      1 Reply Last reply Reply Quote 0
      • d.healeyD
        d.healey
        last edited by

        Might help - https://docs.hise.audio/cpp_api/index.html#introduction

        Libre Wave - Freedom respecting instruments and effects
        My Patreon - HISE tutorials
        YouTube Channel - Public HISE tutorials

        1 Reply Last reply Reply Quote 1
        • Christoph HartC
          Christoph Hart
          last edited by

          It should not be a huge task to write a wrapper for the Gen code using the script node API. There are a few issues though:

          • the Gen code is using namespaces and global functions, which might be a bit annoying to manage (just looked at the example code in their Github repo and they create a global noise object which is a bit weird by today's coding standards).
          • the license of the autogenerated Gen code is not permissive so you need to get a commercial license from Cycling74. Also I can't include the headers into the HISE codebase because they are not compatible with GPL.

          The cleanest way would be to have a .dll containing the Gen code and a wrapper that loads the .dll. There is already a system in HISE that is pretty similar. I used it in a quite old project to load up a 3rd party FX library that wasn't available as source code.

          Link Preview Image
          HISE DSP API

          favicon

          (hise.audio)

          and an example project:

          Link Preview Image
          HISE/extras/script_module_template at master · christophhart/HISE

          The open source framework for sample based instruments - HISE/extras/script_module_template at master · christophhart/HISE

          favicon

          GitHub (github.com)

          It is not compatible with scriptnode yet (it used the pre-scriptnode scripting module system but updating it to the scriptnode API is trivial) and the example project needs to be modified to pick up the generated Gen code.

          This way you could also load these nodes without having to recompile HISE, but you must ship another .dll along with your plugin and make sure that the user can load it (which is a really annoying process because I haven't found a good location on Windows that can be read and written to in all use cases).

          1 Reply Last reply Reply Quote 1
          • C
            clumsybear
            last edited by

            @d-healey cheers man, it helps :)

            you gave me a lot to think about @Christoph-Hart

            I'm aware of the Cycling74 licensing situation. Also it's not it's not exactly ideal to have to ship an external dll along with the plugin.

            So the simpler solution would be to rewrite all the code to SNEX, that way I can export as CustomNodes or could use the DSP in a simple JIT node in HISE, right?

            1 Reply Last reply Reply Quote 0
            • Christoph HartC
              Christoph Hart
              last edited by

              Hmm, actually it would also be possible to create a static library that you can use in the compiled plugin, but this complicated the build process a little bit.

              If you can rewrite it in SNEX, then obviously yes, that would be the best option (also SNEX is a 100% standard compliant subset of C++, so the conversion to a compiled node is pretty straightforward).

              1 Reply Last reply Reply Quote 0
              • First post
                Last post

              15

              Online

              1.7k

              Users

              11.9k

              Topics

              103.3k

              Posts