It is currently Fri Mar 29, 2024 10:48 am


Hauptwerk Memory Footprint

Using the CODM to create your own organ definitions, exchange CODM organ definitions, ...
  • Author
  • Message
Offline
User avatar

chr.schmitz

Member

  • Posts: 374
  • Joined: Sun Aug 25, 2013 11:49 pm

Hauptwerk Memory Footprint

PostThu Oct 26, 2017 1:34 pm

I have screens with several identical controls. Does it make a difference regarding memory usage, if I load the same graphics file multiple times and use it only once, or if I load the graphics file only once and use it multiple times? The 2nd option gives at least the cleaner (shorter) program code.

As far as I understood, PNG compression is useless as Hauptwerk always uses 24 bit PNGs.

Chris
Offline
User avatar

mdyde

Moderator

  • Posts: 15446
  • Joined: Fri Mar 14, 2003 1:19 pm
  • Location: UK

Re: Hauptwerk Memory Footprint

PostThu Oct 26, 2017 2:32 pm

Hello Chris,

chr.schmitz wrote:I have screens with several identical controls. Does it make a difference regarding memory usage, if I load the same graphics file multiple times and use it only once, or if I load the graphics file only once and use it multiple times?


Hauptwerk will load exactly one instance of the file's data into memory for each time that you refer to it by its filename within the ODF (but no additional instances when referenced indirectly via its corresponding ODF image/style object). For example, if you had two separate CODM-ODF.CustomDisplayControlStyle objects that both specified the same image filename, then two instances would be loaded into memory. However, if you had one CODM-ODF.CustomDisplayControlStyle and two CODM-ODF.Stop objects that both referenced it by its ControlStyleID then only a single instance of it would be loaded into memory.

chr.schmitz wrote:As far as I understood, PNG compression is useless as Hauptwerk always uses 24 bit PNGs.


That's correct, in that the file will be stored in memory decompressed. The only benefit of using compression within an image file would be to make the sample set's files smaller (e.g. for faster download).
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Offline
User avatar

chr.schmitz

Member

  • Posts: 374
  • Joined: Sun Aug 25, 2013 11:49 pm

Re: Hauptwerk Memory Footprint

PostThu Oct 26, 2017 2:41 pm

Martin, many thanks for these interesting insights! Now I know, what to do...

Chris
Offline
User avatar

mdyde

Moderator

  • Posts: 15446
  • Joined: Fri Mar 14, 2003 1:19 pm
  • Location: UK

Re: Hauptwerk Memory Footprint

PostFri Oct 27, 2017 6:34 am

Thanks, Chris.

You're very welcome.
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Offline
User avatar

chr.schmitz

Member

  • Posts: 374
  • Joined: Sun Aug 25, 2013 11:49 pm

Re: Hauptwerk Memory Footprint

PostFri Oct 27, 2017 9:28 am

Martin, allow me one additional question:

What is the best way to test Hauptwerk memory requirements?

RAM Free GB before and after loading the sample set?

Chris
Offline
User avatar

mdyde

Moderator

  • Posts: 15446
  • Joined: Fri Mar 14, 2003 1:19 pm
  • Location: UK

Re: Hauptwerk Memory Footprint

PostFri Oct 27, 2017 9:48 am

Hello Chris,

Definitely don't rely on the 'free GB' figure, since it's (mostly) queried from the operating system, and might vary significantly according to whatever else might happen to be running in the background at that particular time on that particular computer, or with paging, etc.

Instead, after loading the organ, look at the 'Approx. est. Hauptwerk sample/obj. mem. (excl. other data)' figure in Hauptwerk's log.
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Offline
User avatar

chr.schmitz

Member

  • Posts: 374
  • Joined: Sun Aug 25, 2013 11:49 pm

Re: Hauptwerk Memory Footprint

PostFri Oct 27, 2017 9:49 am

Hello Martin,

thanks a lot for the lightning fast response!

All the best,
Chris
Offline
User avatar

mdyde

Moderator

  • Posts: 15446
  • Joined: Fri Mar 14, 2003 1:19 pm
  • Location: UK

Re: Hauptwerk Memory Footprint

PostFri Oct 27, 2017 9:56 am

Thanks, Chris.

P.S. That log figure is a (nearly perfectly) accurate figure for the total amount of memory that Hauptwerk itself has allocated (irrespective of whether the OS might since have paged any of it out).
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Offline
User avatar

chr.schmitz

Member

  • Posts: 374
  • Joined: Sun Aug 25, 2013 11:49 pm

Re: Hauptwerk Memory Footprint

PostFri Oct 27, 2017 10:00 am

Great! But hopefully at very low priority :wink:

There are so many other things we are eagerly waiting for...

All the best and have a nice weekend!
Chris
Offline
User avatar

mdyde

Moderator

  • Posts: 15446
  • Joined: Fri Mar 14, 2003 1:19 pm
  • Location: UK

Re: Hauptwerk Memory Footprint

PostFri Oct 27, 2017 10:18 am

Hello Chris,

I don't think I understand your reply? (I wasn't saying that any additional functionality is needed or planned -- you can already see that figure from the log.)
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Offline
User avatar

chr.schmitz

Member

  • Posts: 374
  • Joined: Sun Aug 25, 2013 11:49 pm

Re: Hauptwerk Memory Footprint

PostFri Oct 27, 2017 10:22 am

Sorry, I misunderstood your reply. I thought that you have logged a feature request (that log figure...), that in future versions of Hauptwerk will display more accurate numbers.

Sorry for the confusion!

Best, Chris
Offline
User avatar

mdyde

Moderator

  • Posts: 15446
  • Joined: Fri Mar 14, 2003 1:19 pm
  • Location: UK

Re: Hauptwerk Memory Footprint

PostFri Oct 27, 2017 10:25 am

Aha -- thanks. (To confirm anyway, it's already sufficiently accurate.)
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.

Return to Custom Organ Design Module (CODM)

Who is online

Users browsing this forum: No registered users and 2 guests

cron