Finally a new public build someday soon?

Progress with HourGlass has been somewhat passive and slow for the past few weeks, I have however tinkered with the code every now and then. I hope to be releasing a new build someday soon. The audio sends stuff won’t yet be making it into the new build, as there’s still no GUI code for that. Preliminary BPM-based envelope editing might be in, if I get the GUI logic working properly. (The hassle now is in what happens when changing between the seconds and beats timebases.)

Thanks a ton by the way to all the people who have donated, it is much appreciated! 🙂


This entry was posted in Uncategorized. Bookmark the permalink.

4 Responses to Finally a new public build someday soon?

  1. Skaven252 says:

    Looking forward to updates to this awesome tool. ^_^

    Is it OK to post feedback here, or would you like it sent to a separate address?

    I found one little issue.. not sure if it’s a bug, but it affects the way the Fragment Rate envelope works: the fragment rate is updated only at the rate set by the fragment rate itself. As in, it waits for the delay between fragments to end, before new fragments are played at a higher rate. Usually it’s not noticeable, but it gets problematic at very low rates.

    Let me explain: if the Fragment Rate is set to its lowest (2 Hz, with 100% random), and the rate is then quickly increased to the maximum, the change actually only applies after the longest possible delay between fragments is over (2 Hz = 0.5 seconds, 100% random increases that up to one second). So if you create an envelope that moves from bottom to top in a very short time (0 – 0.1 seconds), it appears as if the program didn’t react to the envelope because it waits for the fragment delay to end before playing more fragments at the higher rate.

    • xenakios says:

      Yeah, I am aware of this behavior but haven’t looked into how feasible it is to fix. Hopefully there is a way to change the behavior without massive code changes. (It does annoy myself enough too, that I have thought about fixing it some day.)

      • xenakios says:

        I implemented some sort of a fix for changing the rate from the slowest range to a higher one. The fix is somewhat hacky and I am not sure if I really like how I did it, but it appears to be working and the behavior is preferable to the previous one. Hopefully I can release a new build with this change sooner than later…

  2. Skaven252 says:

    Thank you for looking into this. Looking forward to hearing it in action when the new build is out.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s