@Myself wrote:
I’m working on an all Podium/Nucleum track (mini track) and will upload in the next day or so.
Okay, here it is. This track was made with Podium and Nucleum (ver0.25 and ver0.26).
Everything is Nucleum with the exception of the kick drum and hats for which I used ephonic and Tessla SE.
Have since created a patch for a kick with Nucleum which I am very happy with but couldn’t be bothered working into this track.
Anyway, have a listen… 🙂
@H-man wrote:
Have since created a patch for a kick with Nucleum which I am very happy with but couldn’t be bothered working into this track.
Anyway, have a listen… 🙂
Hey excellent! Keep em coming. 🙂
I’ve been letting this ‘lil tune loop around winamp,…
Once I’ve finished tweaking presets I will knock up a demo too.
I initially struggled a bit to get some drums out of Nucleum, but finally got what I believe are some usable sounds.
Cheers
I
Uploaded beta version 0.90.
With these last few changes I now feel that the synth modelling is complete. What remains now are presets, CPU optimization and a few UI flaws with the update of the text readout below the dials.
Changes since the 0.27 version:
Swapped the chorus and delay effects. I think it makes more sense to apply chorus before delay.
The chorus effect is now a true stereo chorus, with extended ranges for the delay, sweep and speed dials.
Added separate delay dials for left and right channels to the delay effect.
The two delay dials and the two LFO speed dials have been extended so that the upper half of the dial range selects between tempo-synced beat divisions.
Downloading 0.90 now. I really liked the changes in 0.27 btw. 🙂
Thx Frits, again can’t wait to try it out.
@rinxai wrote:
Hey excellent! Keep em coming.
I’ve been letting this ‘lil tune loop around winamp,…
Thx rinxai. Now working on an airy-trance thing too 🙂
I have two questions about Nucleum performance:
1. When the synth is idle (podium stopped, default Kinabalu patch), moving the FM dials from 0 to full quickly causes a big spike on the resource meter in the bottom right.
2. Occaisionally (no specific example sorry) I find that there is a lag on parameter changes where a change, for example to an FM dial, is not heard until another parameter, filter cutoff for example, is changed.
The first dosen’t seem to have any real impact on workflow however the second can be annoying.
Has anyone seen anything like this on their system?
@H-man wrote:
1. When the synth is idle (podium stopped, default Kinabalu patch), moving the FM dials from 0 to full quickly causes a big spike on the resource meter in the bottom right.
This happens because I’ve put in a check that skips the FM processing when an osc is not FM modulated (all dials set to zero). The CPU spike occurs because SM rearranges the code when the FM processing on/off state changes. I can get rid of this spike by skipping the check and always call the FM processing, but this will result in a small increase in CPU for patches that doesn’t use FM.
2. Occaisionally (no specific example sorry) I find that there is a lag on parameter changes where a change, for example to an FM dial, is not heard until another parameter, filter cutoff for example, is changed.
I haven’t noticed this myself. Does it happen during playback, i.e. during a heavy CPU load? Are you changing the parameter via MIDI CC or the mouse?
@Zynewave wrote:
I can get rid of this spike by skipping the check and always call the FM processing, but this will result in a small increase in CPU for patches that doesn’t use FM.
Okay that makes sense. However what would then happen if you were modulating an FM dial on a low setting with a sine wave that effectively swept the FM dial to 0? Perhaps it’s best if I cook up a test for this tonight and see what the results are.
I haven’t noticed this myself. Does it happen during playback, i.e. during a heavy CPU load? Are you changing the parameter via MIDI CC or the mouse?
Midi or mouse? Either I think, and yes always during playback, and, more often than not under load. 🙂
My computer is a bit glitchy at the moment (plus I have the flu) so I am going to have to re-check this later but is anybody else experiencing long delays or crashes when changing between presets either using the internal preset loader or by switching .fxp files (or equivalent) in a host? I know that earlier versions .fxp files won’t load in the new one so don’t worry that I am getting that mixed up. 🙂 Not a confirmed issue here but I figured it would help to have others looking for it too… preferably other healthier people. 😉
Frits, my ears aren’t up to making a good evaluation of the new sound but I can tell you that the changes you made in 0.90 all seem well thought out for the better. Having the chorus on the left is more logical and I’ll listen to the delay but at least you have given it a fighting chance by expanding the user’s control. 🙂 With a little luck, I should be in shape to test things out in-depth tomorrow.
@Zynewave wrote:
What remains now are presets, CPU optimization and a few UI flaws with the update of the text readout below the dials.
Thanks for the update. I’m sure its not just my imagination but Nucleum is a very lovely sounding synth to my ears. Its like gonna become my top virtual sound source. I could rattle on at length about the awesomeness of this synth but I’ll leave it at that.
The layout and refinement of the effects is much better.
I now have have about 250 presets and growing, with the ‘best’ to be packed into a single bank for release soon. The 0.9 release is a significant improvement and will require going through and re-tweaking presets. So perhaps by this weekend a full bank of Nucleum goodness.
🙂
@H-man wrote:
@Zynewave wrote:
I can get rid of this spike by skipping the check and always call the FM processing, but this will result in a small increase in CPU for patches that doesn’t use FM.
Okay that makes sense. However what would then happen if you were modulating an FM dial on a low setting with a sine wave that effectively swept the FM dial to 0? Perhaps it’s best if I cook up a test for this tonight and see what the results are.
No need to worry. If any of the FM modulation parameters are used in the matrix, then all FM processing is running always.
@Per Lichtman wrote:
My computer is a bit glitchy at the moment (plus I have the flu) so I am going to have to re-check this later but is anybody else experiencing long delays or crashes when changing between presets either using the internal preset loader or by switching .fxp files (or equivalent) in a host? I know that earlier versions .fxp files won’t load in the new one so don’t worry that I am getting that mixed up. 🙂 Not a confirmed issue here but I figured it would help to have others looking for it too… preferably other healthier people. 😉
Which host(s) does this happen in? Have you tried more than one host?
@Zynewave wrote:
@Per Lichtman wrote:
My computer is a bit glitchy at the moment (plus I have the flu) so I am going to have to re-check this later but is anybody else experiencing long delays or crashes when changing between presets either using the internal preset loader or by switching .fxp files (or equivalent) in a host? I know that earlier versions .fxp files won’t load in the new one so don’t worry that I am getting that mixed up. 🙂 Not a confirmed issue here but I figured it would help to have others looking for it too… preferably other healthier people. 😉
Which host(s) does this happen in? Have you tried more than one host?
So far I’ve had it happen in Jeskola Buzz and Reaper. I will load it up in Sonar soon and I will be installing Podium (the version that recently came with CM) sometime this weekend.
My system:
P4 3.2gHz
2GB RAM
Windows XP Pro SP 2
M-Audio Audiophile 2496
On a brighter note, I’ve found that Nucleum sounds really nice at 96kHz. 🙂
I also had the error occur in Xlutop Chainer. The sluggish preset issue seems to have disappeared, but the crashes have now been replicated in 3 hosts. I am still trying to find the common link between the crashes.
They don’t happen all the time. It may be related to changing presets while notes are still sustaining in the current preset. I will continue to test.
So far I have managed to make it crash about 6 times in the last 30 minutes but I haven’t been able to find the common link yet. Simply switching back and forth between presets while sustaining notes doesn’t do it. I thought maybe it was a particular preset text file but I have been able to load it without difficulty at various points in the last 30 minutes as well. *Sigh.*
I will wait to post a while until I have more useful data.
Frits, Per,
I have had this in Podium as well. I didn’t respond right away becuase I thought the issue may have been dealt with in the updates.
It is not occuring frequently however the most recent occured when I was changing presets via the file/load preset action.
I believe that it is related to playback/sustained notes. That is, if I had turned of ‘Monitoring’, turned it back on and loaded the preset, then the hang would not have occured.
The result is a freeze or ‘lock-up’ in Podium and is usually accompanied by a loud buzz. To date I have not been able to recover from this and am left with the CTRL+ALT+Delete & kill in task manager as my only path back to windows.
I should point out here that I almost always have several instances on Nucleum open/activated at the time.
Also, other plugins had produced similar results in Podium. You wa shock is a classic example for me.
Ben