Issue with Multi Display Images not initializing

Hi, there. So I am pretty sure this is an initialization issue, but I've only been using Reaktor for a little while so I'm not too sure on where to go next to solve this problem. I have a Multi Display that's 512x32 pixels with 16 Image objects spaced evenly apart. When I first start up an Ensemble with this instrument in it, the entire Multi Display is blank - as in, it shows the background color (red arrow points to the Multi Display):


This is what it should look like:


The only way I can get the images to show up is by clicking one of them and then Deactivating or Activating the entire Multi Display. Either action works (deactivating or activating). I then have to click another image and either activate or reactivate the entire Multi Display again to make the next one show up. If I click multiple images then only the last one I clicked will end up showing up.

Here is the diagram of where the Multi Display lives:



Like I said, I'm pretty sure it's an initialization issue, but I'm just not sure how to proceed to fix it.

Any help is greatly appreciated.

Thanks in advance.

 

Partly, but I think it is more generally an ordering issue, combined with the fact that the complex Primary level components are a nightmare to use.

Just ensure that for each individual object you update ALL the parameters you are using in the correct order EVERY time you update it. e.g. don't use a constant connected to one of the inputs, use a value module with a constant value driven by one of the active parameters, that way you don't have to worry about initialization as much.
You'll need lots of order modules. I find it's best only to use the 2nd and 3rd order outputs, because the 1st behaves differently during initialization!

These Primary display and table modules will leave you bald before your time

Good luck.

 

Here's an example of how I'm using Primary display modules:



To avoid the spaghetti nightmare of order modules, I drive the display module with a core module. Ordering is a non-issue in core, and I can use a primary iterator (two in this case) to drive the core module. It's cleaner, easier and more powerful this way.

 

Thanks for the help, colB. I think you are right about the Ordering being the problem, since sometimes I would get slightly different results after having changed seemingly unrelated things...

But in any case, instead of troubleshooting it I decided to create 16 32x32 Multi Displays (1 for each image step in the sequencer) and then use a 1->M Router (indexed by X mouse position, quantized) to route the Object updates to the right place and constants for X1,Y1,X2,Y2. I noticed the idle CPU usage went up as a result of adding another 15 Multi Displays, but I'm not interested in efficiency at this point (so long as it works).

And the good news is... it works! I've completed my recreation of the Performer in Massive (complete with the 16 waveforms you can select from in Massive) and I can actually use it as part of an Ensemble to modulate whatever is available.

Now (before I can release anything) I need to bug test it and then start working on replacing messiness and inefficiency with Core macros (once I learn more Core)...

 

The very interesting thing of Colin's structure is, that it shows, how core works here:

all outputs depend on same source (input iter). So all events are simultaneous in core. Now outside they happen from top to bottom.
ciao herw

 

Now that I've been working more in Core I understand why your last statement especially is so important: "all outputs depend on same source (input iter). So all events are simultaneous in core. Now outside they happen from top to bottom." That is very good information to know - thanks!

BD