oh no--not this problem again!

I tried uploading it again, and downloaded it fine on a PC. This could be a Macintosh bug which is reported to NI and they confirmed it is a bug. If the message appears, keep confirming 'ok' until the file opens, then save it, and it should not have the problem again on reopening it. Please let me know if you experience the problem again.

That worked. It took many retries to finally load it the first time, though.

I downloaded Husserl 093b several hours ago and just tried it (Win XP, energyXT 1.4 with Reaktor VSTi) -- got "Sorry, this is an unknown file format!" message but retried (a lot of times!) until it finally worked, then resaved and it now loads normally.

But I'm seeing a runtime problem that wasn't in any previous version I've tried: upon changing the channel on the Husserl GUI, I often get stuttering (meaning that the tempo is off) for a short time after the change, then it rapidly returns to normal; this is usually accompanied by a transient increase in volume which might be due to very quickly succeeding MIDI note ons driving the output synth (XPhraze, in this case) quite hard. This anomaly appears whether or not the SOLO button is on.

I am running Husserl with the built-in synth deleted so that my CPU always remains reasonable (I think), if that makes any difference.

Happy New Year to all,

Greg Williams

Please could you email the ensemble you saved to admin@heavensonearth.com? That would be faster than waiting for customer support at NI to do the same thing. Then I'll see if I can replicate the problem.

Oh, regarding the Mac "file format not recognized" message: NI says it's something to do with instrument/macro nesting behaving differently on PCs and Macs. But that's all they know. They haven't worked out why it happens and can't provide more specific information.

I had to make substantial changes to the logic for multiple output--it added over 4MB of logic alone. But now the structure is built, the object properties and logic can be changed without re-introducing the problem.

Administrator wrote:
Please could you email the ensemble you saved to admin@heavensonearth.com? That would be faster than waiting for customer support at NI to do the same thing. Then I'll see if I can replicate the problem.

Sorry Ernest, we are running up against my limitations here. I have a 24kbaud (at maximum) dial-up connection only and it would take a long time for me to e-mail it, plus I'm not sure my e-mail provider will let me send that big of a file. Anyway, it does load now. Do you _really_ need it from me?

Anyway, on my previous post in this thread, I optimistically assumed that CPU wasn't a problem. Now (another of my limitations) I believe that your matrix switching is maxing out my poor old Celeron 2GHz (blush). A song running on the 093 takes (CPU readout in Reaktor only, not in energyXT) around 8% but switching channels reliably gives "over" momentarily and the little bars at the bottom go all the way to the right. In the previous beta, a similar song takes 5-6% and that readout doesn't change noticeably when I switch channels.

If Husserl is now going beyond my computer's capacity (I don't expect to get a replacement machine anytime soon, unfortunately), could I request a version of the previous (09beta2) with the modulation bug fixed as you did for 093? For now, perhaps 09beta2 is the best I can handle, and its Multi setting works fine for me.

Feeling limited,

Greg

24kbps? I'm really sorry to hear that! Not to worry, someone else promised to mail it back later tonight.

I did some checking. I had a *very soft* single click on some of the old snaps when changing the sequencer channel until I cleared the midi output matrices, set the outputs like I wanted, and resaved the ensemble. The click then disappeared. I am trying to work out exactly why, have no stuttering on changing snaps.

I have had stuttering before because I had inadvertently set one of the controls in the ensemble to be set by MIDI notes. This is easy to do if the properties dialog for the control is open and one presses a key on the QWERTY keyboard while focus is on the knob. This causes the 'useful' MIDI learn mode to turn on. "MIDI in" is automatically activated, and the psanel control learns the MIDI note associated with the QWERTY keyboard. This especially causes stuttering if the control is a switch in an audio instrument, as the audio path is interrupted when the sequencer plays the note. Husserl itself contains no switches.

It is possible that the resave on the Mac format has altered some setting.

It is also possible your CPU is peaking out because of combined screen and MIDI processing overhead when changing channels. It is a good idea to disable all the ports and channels you are not using. Each port adds another real-time interrupt for the system to maintain, and some MIDI software drivers have separate real-time timers for each MIDI channel also. Do you have a CPU meter to indicate what the actual load is on your system when changing the sequencer channel?

Administrator wrote:
I have had stuttering before because I had inadvertently set one of the controls in the ensemble to be set by MIDI notes. This is easy to do if the properties dialog for the control is open and one presses a key on the QWERTY keyboard while focus is on the knob. This causes the 'useful' MIDI learn mode to turn on. "MIDI in" is automatically activated, and the psanel control learns the MIDI note associated with the QWERTY keyboard. This especially causes stuttering if the control is a switch in an audio instrument, as the audio path is interrupted when the sequencer plays the note. Husserl itself contains no switches.

It is possible that the resave on the Mac format has altered some setting.

It is also possible your CPU is peaking out because of combined screen and MIDI processing overhead when changing channels. It is a good idea to disable all the ports and channels you are not using. Each port adds another real-time interrupt for the system to maintain, and some MIDI software drivers have separate real-time timers for each MIDI channel also. Do you have a CPU meter to indicate what the actual load is on your system when changing the sequencer channel?

Good 2009 morning!

I haven't ever touched my QWERTY keyboard with any version of Husserl running. I'll disable all unneeded ports/channels and report the results soon. Both CPU meters in energyXT and Windows Task Manager show bumps when I change channels in Husserl, but they don't peak out, probably because they are relatively slow to respond to the brief CPU spike. I'll look more carefully at these and let you know what I see.

I'll be back,

Greg

Finally, some diagnostic progress, I believe ...

The good news is that I can make the stuttering go away on my low-speed computer: the apparent CPU overload occurs _only_ when a Husserl channel is using the "matrix"/"fugue" trigger. Very repeatable. (I've been using "Snap 10" for trying various possibilities, and these results are with all AUX outs off and only channels 1-4 connected to only MIDI outs 1-4, respectively.)

One other (repeatable) surprise: changing MIDI out settings in Setup is apt to cause "program"(?) changes in the state of the VSTi to which Husserl is sending MIDI. In my case, that is XPhraze, which uses "combis," each consisting of 4 presets. When using an XPhrase combi with MIDI ins 1-4 each going to a corresponding preset (that is, 1-4), changing Husserl's MIDI out settings sometimes TURNS OFF one or more of the presets (don't ask me how, any MIDI in to do this seems undocumented, and I only know how to do this with a mouse in the XPhraze GUI!) and sometimes also resets the preset(s? at least preset 1, for sure) to its default "factory" setting. All that is a surprise and _not_ welcome.

EnergyXT and Windows Task Manager CPU readings do go higher during stuttering, but they respond slowly enough that 100% isn't shown. "Over" does consistently appear (briefly) in Reaktor's CPU readout during stuttering.

I'm very happy that most of the functionality of Husserl 093b is accessible even on my slow Celeron.

Any more questions?

Greg

Greg, please could you let us know what speed your computer is, and it's software/hardware configuration?

I started to do some more thorough testing. The beta was sending controller out messages with a 0 value on snap changes. I disabled that reset, it may clear up the problem. I will post a new beta in a few hours.

Gene has supplied a version with the "file not found error" cleaned up on a Mac. I am adding some extra demo synths on the next beta which hopefully will not add the problem again, as they are block copies. That completes the entire functionality for the 1.0 release, except for snapshots and debugging.

The general adivce on heavy cpu load is to increase the audio latency and reduce the event logic frequency in Reaktor. The ensemble is designed to work no matter what the values for these two Reaktor configuraiton variables.

The ensemble does resend values for all controllers from the p[anel controls when changing sequencer channel. I hadn't found this to add CPU load or cause stuttering on my machine, a 2.6 GHZ AMD X2, and no one else has reported problems. I will try CPU throttling and see if I can replicate the problem.

I take performance issues very seriously, so Husserl 96m is now uploaded. It reduces event triggers on screen redraws by >80% and ensemble size by 3MB.

Also, the setup panel is now on the B panel.

Enhancements:
* ROTATE trigger buttons are now available for the bar sequencer. They are the little buttons just to the top right of each table.
* AUTOSCAN on the setup panel, when enabled, pages through the sequencer screens automatically on load (you must be on the A panel when the open the ensemble. This caches the screen data and improves future panel draw performance.
* Preset button triggers can set the step filter matrix all on or all off.
* Copy/paste of pattern and bar table data now works between snapshots. On launch, pattern and bar tables are restored to the last save of the ensemble, without needing to save the snapshot.
* Updated tooltips (more abbreviated as there is now a manual).

Note, performance enhancements will improve stablity, but may introduce some state issues when initializing. I think I have fixed most of the issues, but there are may be a few cases where screen or buttons don't update like you expect.

Bug fixes:
* Changing the sequencer channel was sluggish.
* The global pitch map scale was snap isolated.
* The setting for 2/1 tempo was 102 ticks instead of 192 ticks.
* The stacking order of the matrices was too flat, so sometimes a click was required to gain focus before a matrix cell could be changed.
* The global pitch map key list was not being hidden when *chromatic* was selected
* The *step/1time* option in the bar sequencer is for fugue mode only. In other modes the control is now hidden.
* Array data boundary errors in sequencer channel 16 were fixed.
* With a matrix source, the *layer* mode was not behaving as described in the manual. The logic is totally redesigned. Note, when gated by a matrix trigger, a sequencer channel in layer mode emits spurts of notes, for example in pairs or triplets. This is because it only makes notes when a note from its triger source is actively playing. As soon as the note is released, it stops.


Todo:
* The polarity of the input filter indicator lights is reversed. They light up when a note is passed, not when a note is blocked.
* Testing and more snapshots