Zynewave's Forum Page
Forum Replies Created
-
ZynewaveKeymaster@H-man wrote:
Actually, it was the ‘File’ button on the Nucleum UI. The menu did not appear because Podium exited immediately.
Then it’s most likely a bug in Nucleum. I’m afraid this is out of my control, as this crash is happening in the SynthMaker engine. I’m hoping that future SynthMaker releases will improve stability.
ZynewaveKeymaster@H-man wrote:
Last night I was using Nucleum, pretty much just creating a new preset, clicked on the save button and BOOMF! ….desktop.
Never seen it before, ever. Podium 1.98, Nucleum 0.93.
Which save button? The save menu in Nucleum or saving the project in Podium?
ZynewaveKeymasterNot so long ago I considered changing this behaviour. It’s on my todo list.
The reason the automation tracks are muted is because, even though the automation tracks are shown as child tracks of the soloed track in compact mode, they are in fact child tracks of effect parent tracks. Soloing a track will solo all child tracks, as well as each parent track all the way up to the master. I need to extend this so that any parameter child tracks of a parent track is soloed as well.
ZynewaveKeymaster@smueske wrote:
No, the application just disappeared, and by that I mean it just vanished. Then when I open Podium, it goes on to the next step as though all the plug-ins are loaded (configuring the arrangement).
Maybe it was just the Podium window that was hidden by the plugin, rather than a crash. Did you verify that the Podium.exe actually exited?
In the quarantine file, do I have to enter anything other than just the full path to the dll?
Just add a line like:
C:Vstpluginssynth.dllZynewaveKeymaster@smueske wrote:
I am having a problem in that I can’t load my VSTs. I’ve identified the problem VST as Halion 3. The problem is that the list populates all the way to Halion 3, then the application just disappears. The next time I load it, there are no VSTs listed. I tried just loading the VST by itself and the same behavior happens, the application just disappears. Now I could just rename the dll, I suppose, but I’d like to be able to use it in other apps.
Is there an exclude function, or some way that I can manually not use that particular instrument in this app? Any ideas on a workaround?
Hi Steve,
When Podium scans for plugins, it writes the full path of the currently scanned plugin to a file named “PluginScanLog.txt”. This file is located at: “C:Documents and Settings[user]Application DataZynewavePodium” folder, depending on which Windows OS you use. It’s the same folder where the Podium.ini file is located. If the plugin scanning causes Podium to crash, then the next time you start Podium you should see a messagebox with “The previous Podium session was terminated while scanning the plugin:” and then the filename of the plugin. Podium will then move the plugin to a quarantine list. Did you see this message box?
Otherwise you can create the PluginQuarantine.txt file manually, and add a line with the filename (with full path) of the Halion3 plugin dll. The PluginQuarantine.txt file should be located in the same folder as listed above.
April 22, 2008 at 20:16 in reply to: New developer tool. Implications for future Podium versions. #12248ZynewaveKeymaster@Pigini wrote:
Before I purchased the upgrade I had downloaded a trial version and made sure Podium could compile on VS2008.
Frits:
Did you compile the 1.98 with it?? That would explain, why it did not work for me. (Tried it only yesterday, since I’m not quick with new versions 😉 ) Though some others, not using win98, found 1.98 not as reliable as previous versions. If you compiled it with the newer compiler, there might be some probs involved with it.No. I haven’t used the new compiler on a Podium release yet. One thing that changed recently was that I got a new Vista PC (previously I was on XP), and during the installation of my development tools I had to upgrade the Windows SDK (source development kit), because the older one I used previously would not install on Vista. That was done before the 1.97 release.
Can you be more specific when you say that 1.98 did not work for you?
Btw. are you the one that voted for Win98 in this topic?
http://www.zynewave.com/forum/viewtopic.php?t=1535April 22, 2008 at 20:04 in reply to: New developer tool. Implications for future Podium versions. #12247ZynewaveKeymaster@Technophobia wrote:
@ Frits. I presume (from the info I found ), it’s something to do with the Windows Kernel that the builds no longer support anything lower than XP ?
Win2000 is still supported. Otherwise it would be totally unacceptable.
While the VS documentation does not go into details about why W98 backwards compatibility has been dropped, it does say that it is due to the updated C Runtime Libraries (CRT). Each major version upgrade of Visual Studio has come with a new set of CRT dlls. Under VS6 the libraries used by Podium were msvcrt.dll and msvcp60.dll. These two files are pre-installed with all Windows versions. For VS2008 the new files are msvcr90.dll and msvcp90.dll. These are obviously not pre-installed on XP and earlier Windows OS, so I’ll need to include those two files in the Podium installer.
The CRT libraries include helper functions for memory allocation, file operations, math operations, multi-threading, text manipulation, etc. So I can imagine that the MS developers have been able to clean up and improve the performance and stability of the newer CRT libraries by removing legacy code that handled the limited functionality of older OS versions.
April 22, 2008 at 18:19 in reply to: New developer tool. Implications for future Podium versions. #12245ZynewaveKeymaster@druid wrote:
I think moving on is necessary sooner or later. I’m mostly for XP minimum requirement (I’m never going back from it), but it does still seem a little unfair. What are some examples of the benefits of the newer compile? Rather than vague references, I mean specific examples?
If by “newer compile” you mean the VS2008 tool, then see my comment below in this post. If you mean the compiled Podium application, then the benefits should be better performance. The UI appearance will not be affected.
Also, do you change anything about Podium’s source code and features? If not, couldn’t you occasionally compile older versions and make them available for those that need them? Or would this require two sets of source code maintenance and/or a lot of time wasted?
Something I didn’t mention in my first post, is that obviously the Visual Studio tool itself has gone through a lot of improvements since VS6. There are many workflow improvements, better debugging features, etc. The actual C++ programming language has also been extended over the years. If I’m going to take advantage of the new C++ language features, it will not be possible to keep compatibility with VS6. I don’t want to maintain two sets of source codes. That would be a nightmare.
ZynewaveKeymasterNucleum 0.94 uploaded.
It was the assembler optimization of the chorus effect that had SSE2 exclusive instructions. This release should again work with older non-SSE2 processor PCs. I fired up my old PIII machine to verify it.
ZynewaveKeymaster@rinxai wrote:
@Zynewave wrote:
….I haven’t experienced the hang problem on my PC.
Which type of CPU is in your PC?Oops, although Nucleum appeared to load, I just got back to check the performance and its still loads with ‘a plugin has performed and illegal action’, and altho appearing in the track, its out of action. Any attempt to remove Nucleum causes immediate Podium hang.
AMD Athlon XP2400
As far as I know the XP processors only support SSE and not SSE2 instructions, so that must be the problem. In my assembler optimizations I must have entered some SSE2 opcodes. I’ll go search for those. I’ll PM you when I have a test version for you to try.
ZynewaveKeymaster@rinxai wrote:
@Zynewave wrote:
I’ve rebuilt the plugin with the previous SM 1.1 beta4, and uploaded a new zip file. The date stamp of the new dll should be 20/04 20:11. Please check if you can load this version of the plugin.
Its working! 🙂
Well, the good news is that it’s not my optimizations that was the problem. The bad news is that I have to be wary when using new versions of SynthMaker. When SM 1.1 final is released I would appreciate it if you could try out a test version of Nucleum. I haven’t experienced the hang problem on my PC.
Which type of CPU is in your PC?
ZynewaveKeymaster@rinxai wrote:
Nucleum 0.93 is not loading here, its hanging Podium, requiring process kill in every attempt.
I’ve rebuilt the plugin with the previous SM 1.1 beta4, and uploaded a new zip file. The date stamp of the new dll should be 20/04 20:11. Please check if you can load this version of the plugin.
ZynewaveKeymasterVersion 0.93 is uploaded:
CPU optimizations. I was tempted to experiment with assembler optimizations to see how much that could speed things up. I ended up replacing most of the code modules with optimized assembler modules. Depending on how complex the patch is, CPU usage is reduced by up to 30%.
While working on the assembler code I found a design flaw that affected oscillators that were being FM cross modulated. This is now fixed. As a result there may be a slightly different sound to some FM patches in this new version.
This version is built with the latest SM 1.1 RC1. Still not the final version.
ZynewaveKeymasterCan I do this in Podium?
Not currently. Support for streaming MIDI between plugins is on the plan.
ZynewaveKeymasterNeed more details. Are you confused because there has been a change in the UI since the last Podium release you worked with?