global send / receive
-
Hey folks, I think I must be missing something with the global send / receive cable nodes.
I set up a send as follows
The receive is part of this script
However when I add this the plugin fails the scan in Reaper and can't be loaded.
-
@ccbl did you turn on Allow Compilation (right click a node) and export it that way? If you do that, the plugin will fail to scan in Reaper and there are no guard rails in HISE.
-
@aaronventure interesting it is possible yes as I was considering testing pre-compiling all my nodes as hard coded FX.
So what you are saying is, if you select Allow Complilation, but then export the plugin without converting into hardcoded FX, those nodes will cause a fail?
-
@aaronventure second question then, will compiling the node as hardcoded FX break the global cables? Or will the work as expected?
-
@aaronventure also I can confirm that solved the problem thanks.
-
@ccbl I haven't tried with global cables, but I've seen @Lindon mention them preventing network compilation.
Also, glad to hear the Allow Compilation flag solved your problem. There really should be a safeguard for that. @Christoph-Hart
-
@ccbl said in global send / receive:
@aaronventure second question then, will compiling the node as hardcoded FX break the global cables? Or will the work as expected?
so you cant use Global Cables or Global Send/Receive nodes and have the network that uses them compiled - you have to run them "as is" not in HardCoded FX modules...
-
@Lindon hmm ok, how much of a performance hit is there, when you don't compile?
-
@ccbl It depends on what your network does.
-
@ccbl should be none in the final plugin
-
@aaronventure said in global send / receive:
should be none in the final plugin
How'd you figure that?
-
@d-healey I vaguely remember reading somewhere about it. It should be the same whether the network gets converted to C++ on project export or on its own first, no? The only difference is some nodes, like SNEX and Faust, require in-HISE compilation first, and if you have a really hungry network, then you can get the CPU usage down by compiling it.
Though it's probably not a bad idea to get @Christoph-Hart to confirm.
-
@aaronventure If that were true there would be no reason to compile the network to a DLL
-
@aaronventure @d-healey @Lindon @clevername27 @Christoph-Hart
This is something we haven't discussed in the last Hise Hang, though it might be a good idea to put it in the priority list, isn't it? -
@ustk said in global send / receive:
@aaronventure @d-healey @Lindon @clevername27 @Christoph-Hart
This is something we haven't discussed in the last Hise Hang, though it might be a good idea to put it in the priority list, isn't it?well getting global cables and global send/receive nodes into a compiled network would be very nice.. no idea how complex it is to do...
HISE Development for hire.
www.channelrobot.com -
@Lindon Yeah absolutely, and to go beyond, it would somewhat inconvenient to be unable to compile a network because you use this or that functionality.
Implemented functionalities should be compatible with the environment they are meant to be used in -
@d-healey well no, you are reducing CPU usage in HISE while developing, and SNEX/Faust nodes need to be compiled first.
Also sometimes you want to blackbox a network and use it in different places with different modulators.
-
@aaronventure said in global send / receive:
@d-healey I vaguely remember reading somewhere about it. It should be the same whether the network gets converted to C++ on project export or on its own first, no? The only difference is some nodes, like SNEX and Faust, require in-HISE compilation first, and if you have a really hungry network, then you can get the CPU usage down by compiling it.
Though it's probably not a bad idea to get @Christoph-Hart to confirm.
@Christoph-Hart What say ye?
