Yuri33

You're half way there. All multidimensional arrays (both the data array and the boolean conditional array) can be flattened to a 1D array which can make use of the 1D templates that have already been created. You then reshape the filtered array to the original dimensions. I don't have access to create XNodes, but that's what I would do.

You could create and maintain a parallel variant hash that indexes your original hash. The attribute names could literally be "1", "2", etc. (or just typecast your enumerators to strings) and the corresponding values would be the attribute names of your original hash. It's a bit of extra bookkeeping, but this is a fairly specialized case anyways. If you want, you could add this extra hash when certain criteria are met (e.g., # of elements, size of attribute names). Either way, you can continue to use method two without exposing yourself to large memory footprints.

I believe his previous job may have had something to do with kidnapping...

Even better is to use the "Panel Close?" notification event. Then you can discard the user's panel close request and perform a controlled shutdown of your program, ensuring that you can run any cleanup subVI's that you require. I actually do this for both the "Panel Close?" and "Application Close?" notification events, so that I can always ensure a proper shutdown.

Rectify and smooth the signal, that way, you only get one trigger per sound packet. If you need to make things as fast as possible, pipe the processed data back into an output channel and configure the appropriate analog trigger parameters. Or alternatively, if the noise is occuring at a specific frequency, there is a single tone frequency detector VI in the signal processing palette. I believe the VI has a window size parameter, so you can have it process data in packets large enough to contain an entire packet of sounds at a time. You could then generate a software trigger when you detect your particular tone.

Have you looked at the Profiler? What subVI is taking the most time, and how many calls are made to that subVI?

Is there a significant hit in execution speed if a VI is opened and executed by VI Server? If that's the case, perhaps we can establish a generalized speed test framework and help people avoid some of the pitfalls of speed testing that were shown in that other thread.

This is my standard LV2-based global stop: Download File:post-7607-1207603671.vi (LV 8.2)

Normally, when you use system controls, you are stuck with system colors and cannot change them. LV produces an error if you try. However, using some inspiration from the JKI guys, I was able to create a set of text contols (simple string and a combo box) where I can adjust the background color of the text. I did this by modifying the classic equivelent with some system control components and some gymnastics. The result can be seen below: Download File:post-7607-1206632349.vi (LV 8.2) However, there is also a simple numeric (included in the above VI) that I wish to exhibit the same behavior. That is, I want it to look like a system numeric, but have adjustable background color like the text-based objects. Unfortunately, I haven't been able to accomplish this. Can anyone get the numeric in the above VI to act like the other text-based objects?

QUOTE (Aristos Queue @ Mar 25 2008, 12:29 PM) I realize that, but if reshape array produced a sub-array, then the only reallocation is for 4 elements: pointer to original array data, new dimensions (whether more dimensions or less than original array), index (=0), and stride (=1). That would be quite efficient. Edit: I'm sorry, I just realize I was mistaken about what is stored into a sub-array. The dimensional information is not stored, only pointer, length, start index, and stride. I guess my focus was on flattening arrays, which is something I do often, and that doesn't require the dimensional information, since all flattened arrays are 1D. I've always used Reshape Array to do this, and it's bothered me that there's a buffer allocation, but AQ's explanation (new dimension information, which is stored inline with the original array) makes sense for a new buffer. Perhaps NI should consider a new array primitive that simply flattens an array--that way it can truly produce a sub-array and be quite efficient.

That's the point, though. In the key binding section of the control properties, you can set page up/down for a specific control, and it will only work for that control. However, you aren't able to do this with the up and down keys. I realize that if you bind up/down to a specific control, then other numerics with increment/decrement would not be able to use the up/down keys when they have focus. But that may be the desired functionality for the program. It's just too bad that LV doesn't allow this, restricting the range of keys that can be unambiuously bound to a specific control.

AQ, does this "stride" array stuff explain why there is a buffer allocation dot in "Reshape Array" even when the number of elements do not change? That has always bothered me. And as a seperate comment, I have to say that while I'm happy that NI has gone to such lengths to optimize this stuff under the hood, it seems like a lot of work for little gain in terms of speed\memory usage. As far as I know, the output of any array native that produces a sub-array (i.e., AQ's "stride "array) either goes to another array native, a non-array native, a subVI, or a terminal. If the sub-array goes to anything other than the first in that list, LV has to automatically allocate a full array before proceeding, which wipes out any gain in efficiency. So the only instances where I could see this sub-array implementation providing significant gain is when you have a whole bunch of native array operations to do consecutively with nothing else in between. Even splitting these operations up into subVI's would destrory the sub-array optimization. As soon as anything has to be done other than a change in indexing, the sub-array has to allocate a full array for itself. Or am I missing something? I do some work with sparse matricies, but I use Matlab for that because it has native functions for operations on sparse matricies, and because Matlab provides lots of complex indexing capabilities. I might be persuaded to do some of that work in LV if NI ever exposes something like this sub-array stuff to us. But I wouldn't hold my breath: the sub-array structure that AQ describes would mean that a pointer to an array in memory would be exposed, and that's a no-no for NI.

I haven't done the test in a while, but I believe that the native implementation was much faster than the dll one supplied by NI (hence the reason I built the subVI). Also, while I've never needed to, the start index can easily be incorporated by selecting a different column (instead of hard-coded 0) to index from.

QUOTE (Justin Goeres @ Mar 20 2008, 10:04 PM) Yes, I forgot to stipulate that my code only works when the array can be evenly divided by the decimation factor. I use that function in a program that ensures this condition elsewhere. The later modification that fixes this problem is good solution that doesn't sacrifice speed.

I find this to be the most efficient (and fastest) version: