"unmoduling" modules

Tom7777 · 17 Dec 2005

Why not just copy and paste the contents of the module? As for the question i think the more levels of a module there is the more cpu ect gets used but im not sure, when working on projects and only having one or two levels with loads of stuff there seems to be a big slowdown when working in SM, not sure if this is the same for exported vstis though and also this will be fixed for better performance soon.

fritzman · 17 Dec 2005

Tom7777 wrote: Why not just copy and paste the contents of the module?

Imagine a module with 50 connections to the outside of it and you wanna "unmodule" it. 😉

Tom7777 wrote: As for the question i think the more levels of a module there is the more cpu ect gets used but im not sure, when working on projects and only having one or two levels with loads of stuff there seems to be a big slowdown when working in SM, not sure if this is the same for exported vstis though and also this will be fixed for better performance soon.

About the CPU issue: I think I read somewhere that the module containers get "compiled away" when making a VST. I would like to know if anybody made some tests if this really works.

Best wishes, FRitz

Tom7777 · 17 Dec 2005

Imagine a module with 50 connections to the outside of it and you wanna "unmodule" it. 😉

Ah yeah thinking about it that way i see what you mean 😀

fritzman · 17 Dec 2005

Tom7777 wrote: Imagine a module with 50 connections to the outside of it and you wanna "unmodule" it. 😉

Ah yeah thinking about it that way i see what you mean 😀

🙂

sambean · 17 Dec 2005

fritzman wrote: About the CPU issue: I think I read somewhere that the module containers get "compiled away" when making a VST. I would like to know if anybody made some tests if this really works.

I think the connections are compiled away.. Here's a quick test:

Make a small section of stream code, say a few additions in series and to this connect an analyser. From the analyser attatch a text box to look at the generated asm. Now if you select a section of your code and keep pressing the make module button, the generated asm doesn't change, no matter how deep you make the modules.

So I don't think we have to worry about grouping things into modules.

Sam

mookid · 17 Dec 2005

I agree with sambean.

Compilers normally parse information like this as it is only aesthetics relevant to the person writing the code. For instance a C compiler will parse the comments and line-breaks from source code. The computer doesn't mind how illegible the resulting code will seem to the users point of view, as long as the code flows in a correct and logical way all should be fine. I'm sure that a nest of 50 modules would build the same as a project with none, just the same as the send/receives shouldn't make any difference too.

fritzman · 18 Dec 2005

Thanx Sam and thanx mookid for the clarification! Glad to hear that SM is designed cool at that corner. I'm sure the rest will straighten out, too.

Best wishes, FRitz

malc · 19 Dec 2005

I can confirm that too. For the compiled parts (poly,mono,mono4) the module depth makes no difference. This is a key part of the design to make the sample rate parts run with maximum performance.

Triggered (green) data is not compiled and therefore will be affected very slightly by the number of modules and links in use.

fritzman · 19 Dec 2005

malc wrote: I can confirm that too. For the compiled parts (poly,mono,mono4) the module depth makes no difference. This is a key part of the design to make the sample rate parts run with maximum performance.

Cool Malc,

thanx for the official word.

malc wrote: Triggered (green) data is not compiled and therefore will be affected very slightly by the number of modules and links in use.

Hm, how slightly is slight? 😀

Best wishes, FRitz