Zynewave's Forum Page
Forum Replies Created
-
ZynewaveKeymasterThanks for your comments,
The incomplete guide is indeed what is holding me back from promoting Podium. Once it is done, I’ll probably start out by putting Podium on download.com, buy banner-advertisements on e.g. kvr, approach music magazines for reviews etc.
I have no plans at all of getting Podium into a box and onto shelves in stores. That may still be a huge market but I believe that online sale of software is the way to go. As a one-man company I certainly never will have the resources to market and sell Podium as a boxed product.
Frits
ZynewaveKeymasterI’ll start experimenting with inlining the sequence/sound editor windows. I don’t think it will be like the new list page. Rather I will try to put it into the arrangement editor as a new region type. Similar to how the mixer region works. But I may change my mind.
ZynewaveKeymasterI wonder if Podium can operate as a multithreaded application? Maybe the gui split that Frits spoke of earlier in this thread falls into that category.
There are plenty of threads in Podium. The audio processing is one thread only, so that is why it cannot be split to multiple processors. There are other things in the engine that runs in separate threads, so that will benefit from multiple processors also. The GUI is also a separate thread.
ZynewaveKeymaster- Embedded list page in browser.
- MIDI note transpose setting on tracks.
- Bug fixes.
May 24, 2005 at 21:50 in reply to: Restricted to Podium license ownersZynewaveKeymasterThis content is restricted to Podium license owners.ZynewaveKeymasterI have not yet had the chance to test Podium on dual CPU systems, or on the Windows64 beta OS.
When running on dual CPU-systems, the engine (and thus all plugin processing) will only utilize one CPU. The Podium UI will however be able to run on the second CPU, so you can consume close to 100% on the engine CPU without causing the UI to get sluggish.
The Podium application uses only standard Windows functions, and the installer is using the Microsoft Windows Installer database, so there should be no problems running it on the new 64-bit OS.
May 24, 2005 at 17:05 in reply to: Restricted to Podium license ownersZynewaveKeymasterThis content is restricted to Podium license owners.May 24, 2005 at 16:32 in reply to: Restricted to Podium license ownersZynewaveKeymasterThis content is restricted to Podium license owners.May 24, 2005 at 15:41 in reply to: Restricted to Podium license ownersZynewaveKeymasterThis content is restricted to Podium license owners.ZynewaveKeymaster(I don’t know how to send you a regular email)
The email-address is listed on the contact page.
When I load your project they appear as in your ‘old’ screendump. If I change the sample-rate in the arrangement properties from 48000 to 44100, then the automation curves will appear like in your ‘new’ screendump. Could you verify that your problematic arrangement is set to 48000? Changing the samplerate will however also scale the audio events, which you say are ok. Are your soundfiles recorded in 48000?
One of my items on the future plan is samplerate conversion. Currently you need to have your soundfiles in the same samplerate as the arrangement is configured to.
ZynewaveKeymasterThat is indeed weird. I don’t recall changing anything in 1.31 that should influence this. Could you email me your ‘good’ project file, without the wave files?
On the PC where you went from 1.31 to 1.30, did you save the project with the 1.31 version?
ZynewaveKeymasterSo turning off the waveform should help ?
Yes it would. But I’d rather spend time on optimizing the waveform display. It should be possible to make the graphics very smooth.
ZynewaveKeymaster@acousmod wrote:
when we move the slider of an automation parameter (mixer or vst) for setting the values while in pause, the point is always recorded as Bar, even if it is the Line mode which is selected in the curve editor. This is very annoying, especially for volume envelopes…
What do you think about Frits ?
The edit mode of the curve editor has no relation to the actual curve sequence, so the mixer cannot use this setting to decide the type of event it should create.
I can imagine certain situations where you would want to create bar events, if you e.g. are using level automation to mute certain passages. What I could do is to create a bar/curve point depending on the type of the neighbouring events in the curve sequence. If you start with an empty curve sequence, the first event created will be a bar event. If you go in and convert this to curve events, then subsequent mixer fader movement will create curve events. This would apply both when playing and when stopped. Good solution?
ZynewaveKeymasterI think it is the graphical waveforms of the audio files that are the major cause for the slow graphics update. I don’t think the meters are to blame. Try to hide the audio events, either by sliding them out the top of the window or by maximizing the mixer region. Does the mixer meters then become more responsive?
I will put on my list that the audio event drawing should be optimized.
ZynewaveKeymasterGenerally I try not to make any promises of when certain features will be implemented. There are a lot of feature requests being made, and putting a time estimate on all of them will just put me under a lot of stress. The development plan is changing frequently too, which futhermore makes it difficult to set deadlines for major features.
The things you mention here is on the plan, but I don’t think I will have all of them ready for the end of June.