elburz_s

Im new to learning max and have decided to start with a project I thought would be a good addition to peoples tool box. I'm basically trying to make a factory style punch in clock for your Ableton sessions that you can load onto the master channel (and save in your default template) that keeps track of how long you've been working on a session. There's more advanced things I'd like to add over time like a function to turn it off if you've been idle for a certain amount of time, etc, etc.

The problem that Im having is with wrapping my head around how to get the clock time to save with your set, and then load up and pick up from where it left off. I've been trying a couple of different things, but I may be over-complicating the situation. I copied my last attempt below, which was using clocker, which is being unpacked to a clock, but also using pattrforward to send the time back to an addition stage right before the clock. I've also connected the clock to constantly store a preset in a pattrstorage every time it clicks, but I think it just ends up saving whatever time it is before I close the patch, and then immediately over-writing it back to 00:00:00 when the patch loads (which is why I was experimenting with live.thisdevice vs the loadbang trying to recall the pattrstorage sessiontime)

I feel like it should be simpler to have a clock that saves and picks up where it's left off, and that my inexperience is making it super complicated! Any help or advice would be greatly appreciated.

Im new to learning max and have decided to start with a project I thought would be a good addition to peoples tool box. I'm basically trying to make a factory style punch in clock for your Ableton sessions that you can load onto the master channel (and save in your default template) that keeps track of how long you've been working on a session. There's more advanced things I'd like to add over time like a function to turn it off if you've been idle for a certain amount of time, etc, etc. 

I feel like it should be simpler to have a clock that saves and picks up where it's left off, and that my inexperience is making it super complicated! Any help or advice would be greatly appreciated.


m4l-stop-clock-saving-questions

Remember that live.* objects (eg live.numbox) save and recall their value automatically with the Live set.

As an example, here is a simple counter that keeps its value between sessions.

Just make sure to always save the Live set when closing.

As an example, here is a simple counter that keeps its value between sessions.
Just make sure to always save the Live set when closing.


Thanks for the reply, I was just getting into experimenting with live.* objects. This saves! That's step in the right direction!

The only problem is that the ticks into the live.numbox are "undo-able" by Live in the "Edit" menu. So for instance if I do something then wait 10 or so seconds, I not only have to hit undo for the clock to go back before I can undo the actual musical change, but then the clock is also thrown back. Do all of the live.* objects react similarly? Do you have an idea to get around that?

Thanks for the reply, I was just getting into experimenting with live.* objects. This saves! That's step in the right direction! 

The only problem is that the ticks into the live.numbox are "undo-able" by Live in the "Edit" menu. So for instance if  I do something then wait 10 or so seconds, I not only have to hit undo for the clock to go back before I can undo the actual musical change, but then the clock is also thrown back. Do all of the live.* objects react similarly? Do you have an idea to get around that?


Searched the forums and saw you mentioned that the live.object writes to undo history in another thread. Do you think it would be easiest to get around that by using non max4live storage of data like pattr?

I don't think that pattr will help as it basically makes a Max object behaving like a live.* object.

Generally I guess that any object which is saved with the Live set will also effect the undo history.

Alternatively, you could try using closebang and loadbang to save and recall the clock.

But so far I've never used closebang in an M4L device.

I don't think that pattr will help as it basically makes a Max object behaving like a live.* object.
Generally I guess that any object which is saved with the Live set will also effect the undo history.

Alternatively, you could try using closebang and loadbang to save and recall the clock.
But so far I've never used closebang in an M4L device.


Out of curiosity I've experimented with closebang and found a possible solution by saving the clock in a file.

The file is global and created automatically in the Max app folder without user interaction.

Creating separate files associated with individual Live sets would be the next step.

Out of curiosity I've experimented with closebang and found a possible solution by saving the clock in a file.
The file is global and created automatically in the Max app folder without user interaction.
Creating separate files associated with individual Live sets would be the next step.


Thanks again for looking into it, I'll mess around with these ideas tonight and see where I'm at!

Ok, I fooled around with it for a bit and tried to combine the 2 patches into one. I've made it to having it count 1 every time you open and close the project, I guess with the closebang saving 1, then another being added on the loadbang. I tried changing the patching, but could get the metro at the top to send clicks down into the numbox. I tried switching the 1st trigger in the chain to have a couple of bangs and sending them off in different orders to try and trigger the read and write of x more often, but couldn't figure it out for some reason.

Also curious as to the effect of sending the metro into the trigger, what are the benefits of that? Is that to simulate sending ticks of 1 (so that we dont need to use a translate ticks hh:mm:ss?), or is it just a little easier to work with? I also couldn't seem to figure out where it would be appropriate to use clocker as opposed to metro and vice versa, or maybe I read it somewhere and didn't understand!

I've used metro instead of clocker to provide a simple continuous clock across multiple sessions.

Obviously, the clock (seconds) can easily be displayed in any other format like hh:mm:ss.

Here is a corrected version of your combined patch.

I've used metro instead of clocker to provide a simple continuous clock across multiple sessions.
Obviously, the clock (seconds) can easily be displayed in any other format like hh:mm:ss.
Here is a corrected version of your combined patch.


Ah ok, I see what you did, and it works which is great. Just curious why the different result? Does the data coming out of coll need to "become an actual number" first or something? (Lol noob alert!)

At this point I'm thinking even if the user had to manually save a text file once per project, it wouldn't be the end of the world, although I'll look into somehow autosaving. Im thinking maybe seeing if M4L can see what the project is called and then just autosave a text file in the same folder (or if that proves difficult, just wherever it feels like defaulting as long as it's not the desktop) with the name that M4L sees as the project name. I'll experiment!

And from there I don't think a very simple UI will be hard at all. I can see the finish line!

At this point I'm thinking even if the user had to manually save a text file once per project, it wouldn't be the end of the world, although I'll look into somehow autosaving. Im thinking maybe seeing if M4L can see what the project is called and then just autosave a text file in the same folder (or if that proves difficult, just wherever it feels like defaulting as long as it's not the desktop) with the name that M4L sees as the project name. I'll experiment! 

And from there I don't think a very simple UI will be hard at all. I can see the finish line!


M4L Stop-clock saving questions