Topic: New developer tool. Implications for future Podium versions.

Viewing 5 posts - 46 through 50 (of 50 total)
  • #12455
    acousmod
    Participant

    Hi,

    My personal dream – but surely no priority for Frits or for the long-time users here – would be the way XT went – meaning you could load Podium as vsti inside another host.

    Excuse me, but I really don’t understand this 🙁

    I understand using a modular sequencer like Ext 1.4 or Usine in a main DAW, I understand synchronizing two DAWs, I understand using some tracks of one together a second one with Rewire (or Rearoute), but I don’t see what could be the benefit to have a VST version of a full size DAW like Podium running inside a track of another one…

    Can you explain me ? (just curiousity !)

    #12456
    Pigini
    Participant

    In cases where the other app has a similar feature set, it might not seem to make much sense (technically speaking), but it could work out cashwise anyway. I can imagine ppl buying and using it, because then they don’t have to make up their mind and give up the app they are used to. So they can combine both, getting to know podium better while not having to give up their other prog completely. Making it easier for them to justify spending money on it.

    With some other apps it could make more true sense. There are apps supporting vst which did not start as a typical host and therefore have some inherited weaknesses which podium vst could compensate for.
    Those apps might have some strength in some special features making it worthwhile using them.
    (Notation programs with vst support, or DAWS with more of an audio-editor or harddiskrecording background, with only limited implementation of midi and automation etc.)
    Klemperer, since it’s your idea, was that roughly what you had in mind?

    As I mentioned earlier, it would not change much for the users here working with podium as their main host already. But I can imagine, it would draw attention and generate a considerable cashflow.

    #12466
    Pigini
    Participant

    @Pigini wrote:

    …so it’s the same as on my win98se (tested on 3 different comps btw).
    1.99 gives the runtime error after starting an arrangement (It was all a fresh start, there were no leftovers from earlier versions or older projects or such.)
    1.98 brought up the arrangement screen alright but froze when actually starting the engine.
    Is there anything like a debug mode I could activate, like some line in the ini to give more detailed info?

    ..just bumping up the last “on topic” message. so it doesn’t get overlooked.

    #12468
    Zynewave
    Keymaster

    After a long night of debugging I have now finally figured out why Podium 1.98 and later versions can crash on Win9x. I dug out my old Win98 harddrive from the back of the closet and replaced it in my old Pentium3 PC. I got the crashes with 1.98, but not with 1.97.

    The problem is related to the limited number of system resources that W9x can handle. Googling reveals that it is a very common problem for larger applications. This page has a good explanation:
    http://apptools.com/rants/resources.php

    The thing that happened in Podium 1.98 was that I created the resizable toolbars. This required allocation of an extra set of large bitmaps that is used when generating the resized images. These extra bitmaps has pushed the number of bitmaps beyond what Win9x allows. If you e.g. delete the edit toolbar in the arrangement editor profile before entering the arrangement, you won’t get a crash when opening the arrangement editor because Podium doesn’t need to allocate the bitmaps for the edit toolbar.

    I could spend a lot of time trying to reduce the number of bitmaps that Podium uses, but in my opinion that is a waste of time. It will restrict the things I can do to improve the UI in future Podium versions.

    So unfortunately I’ll have to drop the claim that Podium is Win9x compatible.

    #12470
    Pigini
    Participant

    Thanks for caring and taking the time to look into the problem so thoroughly.

    I was expecting w98 compatibility to be maintained only if it did not create any extra work. The time is, of course, better spent on further development, that benefits all and might even hold new solutions for me. For example, extended syncing capabilities for running along in a multi computer setup, could make audio and midi timings more stable on xp and make the reasons I keep running w98 on the big setup obsolete over time.

    And I guess, if it was not for the bitmaps now, it would probably break the resource barrier on w98 soon with some other new feature. The page about the differences in resource management is an interesting read. It gives a good explanation why w98 seemed to be unreliable for some ppl generally using it, while it can run rock solid with a streamlined system doing only very few dedicated things at the same time.

    1.97 will stay on w98, while I continue following the podium story with my xp laptop.

Viewing 5 posts - 46 through 50 (of 50 total)
  • You must be logged in to reply to this topic.
© 2021 Zynewave