Zynewave@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.dll
Zynewave@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.
Zynewave@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=1535
Zynewave@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.
Zynewave@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.
ZynewaveNucleum 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.
Zynewave@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.
Zynewave@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?
Zynewave@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.
ZynewaveVersion 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.
ZynewaveCan I do this in Podium?
Not currently. Support for streaming MIDI between plugins is on the plan.
ZynewaveNeed more details. Are you confused because there has been a change in the UI since the last Podium release you worked with?
Zynewave@H-man wrote:
1. There doesn’t seem to be anyway to get back to the default bank
I’ll include the default bank as a file in the banks folder.
2. The preset list in the Inspector doesn’t reflect the program names for the new bank.
Use the “update programs list” menu command in Podium.
ZynewaveVersion 0.92 is uploaded:
Fixed the bugs with the readout label under the knobs.
Added triplet and dotted options to the delay and LFO tempo sync options. You need to adjust these dials if you have made presets using tempo sync.
Modified the readout labels for octave, semi, fine and the panners.
Added 20 programs to the default bank made by H-man.
Added a “Banks” folder to the zip, containing the almost full bank made by rinxai.
I have no further todo things on my notepad (for v1.00), so please notify me if you find bugs. 0.92 is still made with the SM 1.1 beta, so I will only release Nucleum 1.00 once the final SM 1.1 is released.
Zynewave@rinxai wrote:
There are a few minor issues with sounds that modulate in some ways when no modulation nor fm is active. Somewhat like an unpredictability in output, which can sometimes add interesting character, and sometimes not. Its quite subtle but is noticeable on certain presets. More details once pinpointed.
Couldn’t it be the chorus? Try disabling the chorus (dry/wet to 0) and see if it goes away. The chorus and delay are global effects that run continuously, so notes playing through the chorus may vary depending on where the chorus modulation is at the note-on time.