pavouk100pavouk100@Conquistador wrote:
@pavouk100 wrote:
I can’t see any other reason than ‘my whole system is x64, so all apps have to be x64, so that it nice to look at’.
I can’t see any reason why features you want like flexible MIDI routing or Composite tracks for MIDI are no more than something nice to look at as well = has no interest for me. 😉 But I can quite easily accept everyone has different needs. My comments earlier are suggestions for Frits (even if I think feature x or y is overdue) they are still just suggestions not demands.
You’re right, my comment was dishonest and I apologize for it.
Still…
1. To avoid using any 3rd party “bridge”…which will also side step having to track another dev for support issues, fixes and patches.
But this can be useful only if you are forced to use 64bit plugin, AFAIK there are not so many (if any) which are 64bit only, and not so many for which it would be useful to use 64b instead of 32b (samplers with huge sample libraries come to my mind as the only real case).
2. Dropping the need for a bridge also means less chances of crashes and as a result increased reliability. This KVR Jbridge thread has plenty of user posts posting issues. The Jbridge dev can only do so much as a single dev. There are a ton load of native x64 plugins that are currently available now at different price points to suit pretty much every need. No need for a bridge. I will add that the Jbridge dev has done very well and garnered many users. But if I can side step using a bridge I will do so everytime.
See above; bridge is needed only in very few cases, in other cases 32b variant of the plugin is sufficient.
3. Competition – x64 support is an expected feature now compared to other competing hosts, not some esoteric, obscure luxury feature that is distracting the development process for Podium or threatening to. Frits no doubt has a timetable for it (this year, next or beyond) as he has the inside info on what is best for Podium I trust any decision he makes would be the correct one. 😉
Thats all nice, but… what is it actually useful for? The fact that something other has it does not increase the usefulness of any feature at all – IMHO of course.
pavouk100@Conquistador wrote:
1. An x64 version.
I cannot really consider Podium for serious use as my setup is all x64 now. Also things have changed so much on the x64 landscape that only a few DAW’s remain without x64 support…(including Podium). This is now essential for me and IMO way overdue.
Out of curiosity, what is the reason for 64bit version? IMO, having 64bit OS makes a lot of sense over 32b one, but running 32b apps on 64b OS is perfectly ok, there is no performance degradation AFAIK. I can’t see any other reason than ‘my whole system is x64, so all apps have to be x64, so that it nice to look at’. The only justifiable reason I know is that someone uses sampler and actually loads more than 2GB of samples in single session (yuck!), but AFAIK this can be handled by running 64b sampler plugin through jbridge (or how is that thing called), no?
pavouk100Sure. Current solution is much better than what I originally suggested. Thanks 🙂
pavouk1001 – Support composite tracks also for MIDI, not only for audio
2 – Flexible MIDI routing and plugins support (ideally capable in the same way as audio, i.e. support for busses, groups, etc).
3 – Quick way to split existing events at the point of mouse cursor (sth like modifier-click)
4 – Possibility for vertical zoom of audio events contents in track view (i.e. not whole event hieght, just the waveform picture in it).
5 – Time stretching/pitch shifting of individual audio/midi events
pavouk100I vote ‘snap point’ too because I’m used to it from old Cubase days 😉
pavouk100@Zynewave wrote:
2: Using the Shift key shortcut to activate relative snap.
I prefer solution 2, as I think it will provide a faster workflow, and you are not always in doubt whether relative snap is enabled.
IMHO solution 2 is better. There is yet another possibility, idea stolen from cubase; implement ‘snap-point’ setting in event. This means that you can set up snap-point in the event (similarly as you set up fade-in point in event), and the event snaps automatically to the snap point instead to its beginning. I’m not sure if this is better or not, just throwing in the idea…
Pavel
pavouk100The problems are reproducible for me on Win7 x64 machine, now I tried it also on XP, and it works normally here (should’ve tried it before posting 😳 ). So it might be caused by one of: too new(?) gdiplus.dll, Win7, 64bit OS, asio4all, core i7 CPU, or whatever else, or some combination of these factors .
Never mind, I can live with this. Thanks a lot for your effort 🙂
Pavel
pavouk100@Zynewave wrote:
I installed a bunch of Bootsie plugins a couple of months ago, and gradually almost every one of them has crashed at random during plugin scanning. Something scary is going on there. If the problem also exists for Cubase users, I’ll assume the Bootsie developer is aware of the problem and is trying to fix it.
Sure, these are ‘normal bootsie plugin crashes’. But this Ferric 1.5 is really new thing; simple scenario:
1. install ferric tds 1.5 on the track
2. make it visible (E), twist some knob in it
3. start playback
4. change color of the track clicking inspector’s color picker
results in: hiding plugin’s window at point 4 (ok, sometimes even at point 3), and also causes quite long audio dropout at point 4.
Seems so strangely tied to the host that it could be somehow interesting even for host developer.
pavouk100@Slomo wrote:
A couple of hours ago Podium crashed when scanning Variety of Sound’s Density mkII v2.02 plugin. I recall having problems with these plugins before.
Yep, this is ‘known issue’ to me – all older bootsy’s plugins cause instability when using more than one instance of any of them (this includes scanning). I usually use only one of them for ‘mastering’ purposes. These kind of crashes also roughly match the instability of these plugins often reported by Cubase users, so I didn’t bother to report it here. But Ferric’s behavior described above is something really new and weird to me, that’s why I reported it.
pavouk100@Malcolm Jacobson wrote:
Reaper scans for new plugins …. You can then create as many Project files (equivalent to Podium projects) as you want without having to rescan the plugin database.
I think that the main difference is that emphasized part is not completely true. I’d say that reaper’s project is more like podium’s arrangement, while podium’s project is something like reaper’s ‘group of projects + some global settings, like VST’s db’. While I like the way podium handles this, from the feedback on the forum I’d say that most people would rather go with more traditional reaper/cubendo/other-hosts project/settings management.
pavouk100You have somehow switched editor profile from piano roll to MIDI event list. Go to ‘View’ menu of the window which appears after dbl-clicking event, and choose ‘Timeline’ item (1st active item in my installation).
pavouk100@Malcolm Jacobson wrote:
[*]When I moved a knob in the Camel Space UI the movements were recorded as a Podium parameter track, but they had no affect on playback.
I had similar problems with freebie Camel Crusher. Maybe that Camel Audio plugins are the culprit…
pavouk100@Malcolm Jacobson wrote:
+10 to separating the plugin database from the Project/Arrangement management.
I would use the Project function a lot more if I didn’t have to do a full VST scan each time I create a new Project. At the moment I have lots of Arrangements, but only one Project per Podium release.
Hmm, the same with me, although I don’t have project per Podium release, but only 3-4 global projects, with many arrangements. I like it this way, I don’t see what’s wrong with it. I’d guess that this is the intended usage…
EDIT: I think that ‘project’ is a bit of misnomer. I think that more proper names would be something like ‘Studio’ or ‘Virtual Studio Setup’ or some such.
Pavel
pavouk100@kyran wrote:
There is no general rule to all of this 🙂
I mostly don’t have good sounding rooms available to me when recording, so I try to get everything as dry as possible. I try to use dynamics as much as possible, because they contain less room.
But now you’ve got me interested, so the next time I’m going to try your method as well 🙂
Yep, I’ll try the same with your method. It’s always interesting to try something new 😉
@kyran wrote:
(Again: I’m no specialist, I sort of rolled into recording bands, I’m still learning, and as the audio track I posted proves, there’s lots of room for improvement 😉 )
The same with me; I’m just self-taught amateur helping friends to record, not a studio-pro.
btw, I decided to make short demo clips of recorded (not yet finished) songs, you can listen&judge here:
http://soundcloud.com/curvedsound/sets/pk-sound-samples
pavouk