@Zynewave wrote:
Clicking the piano roll keyboard will keep the note playing until the mouse button is released. Dragging up or down the keyboard will retrigger the played note. The clicked horizontal position controls the attack velocity.
Works great. Thanks a lot!
FRs are flying here, so I’ll release another one 😉
It would be nice to add MIDI velocity sensitivity according to the place where the piano key is clicked. E.g. clicking at the right generates full velocity (loudest) note, clicking at the left generates softest note (minimal velocity), clicking in the middle generates half velocity note etc. Also, leave the note playing since the key stays ‘clicked’ (i.e. generate note off when either mouse button is released or when mouse cursor releases note area).
Yes, it works now. Thanks a lot!
Sample project file sent to info@zynewave.com. The executable I’m running is:
Podium208_beta9.exe
Size: 3.97 MB (4,169,728 bytes)
Modified: Thursday, January 08, 2009, 7:55:00 PM
I’m sorry, but beta9 behaves identically to previous versions, the bug does not seem to be fixed 🙁 Any stereo – mono device chain I’ve tried behaves this way. Let me know if I can help you in any way (more explanations, sample projects files, whatever) …
@Zynewave wrote:
Fix: The track solo changes introduced in 2.06 had the effect that bouncing the master would not produce sound if Automatic Solo was enabled on the bus returns.
Works fine now. Thanks!
I haven’t chance to try with audio tracks, but I tried compositing track feature on MIDI track and failed like this:
1. Recording on MIDI track with loop activated does not put the track into composite mode.
2. When setting the MIDI track manually into composite mode, recording on it does not create ‘take’ subtracks, instead new recording is merged into already existing single lane (i.e. the same behaviour as pre-2.08 versions).
3. When done, the recorded event has the bar on the bottom (the one used to choose proper part of the takes), although it is useless – there is always only one event to choose.
Am I doing something wrong, or is MIDI comping not working yet?
Pavel
Many thanks for the file. The freeze bug is now fixed in the new beta8.
Confirmed, doesn’t freeze any more. Thanks!
@pavouk100 wrote:
@Zynewave wrote:
@aMUSEd wrote:
Oh great – now I’ve clicked on the B button again and the whole app has frozen.
Thanks for testing.
Can you remember if the bounce track was set to offline or realtime bounce mode? I.e. did you see the render progress dialog when the app freeze occurred?
I also experienced app freeze a few times, after offline bounce; bouncing indicator window appeared, progress bar was running, and when it ran till the end, the whole app froze and I had to kill it. It was with beta4, will try it later with last beta.
Beta7, still the same problem. I’ve an arrangement in which it is possible to consistently reproduce – click ‘B’ button, progress bar appears, goes through, finishes, progressbar disappears and the whole app is frozen, eating 100%CPU. Do you want me to PM you the .pod file, Fritz?
@Zynewave wrote:
@aMUSEd wrote:
Oh great – now I’ve clicked on the B button again and the whole app has frozen.
Thanks for testing.
Can you remember if the bounce track was set to offline or realtime bounce mode? I.e. did you see the render progress dialog when the app freeze occurred?
I also experienced app freeze a few times, after offline bounce; bouncing indicator window appeared, progress bar was running, and when it ran till the end, the whole app froze and I had to kill it. It was with beta4, will try it later with last beta.
@Zynewave wrote:
Tell me if I’m taking this too far 😉
It is definitely further than most DAWs are, but I like it very much. Useful, flexible, easy-to-see what the current status is. Mixer is going to be much more useful now.
Yes, please, this sounds simply awesome! (I mean file-based templates :lol:)
@rinxai wrote:
I think that yes it is acceptable, and probably a fortuitous move. Personally, I don’t see much benefit in supporting W98, especially if a lot of work is involved in maintaining support for ‘legacy’ OS as well as moving forward with current M$ compiler.
+1 😆
@Zynewave wrote:
Podium currently supports loop-recording by using a folder track to contain the multiple takes on child tracks. It’s possible to extend this functionality to handle the individual tracks in the group as multiple takes, with automatic cross-fading and automatic muting, etc. I think the best solution is to extend the Podium folder track system to handle multiple-takes, rather than adding a new layer/virtual track feature to each audio track. Implementation of this is a bit into the future though.
+1, great idea. Looking forward to the future when it will happen 😉