If you're in Scotland, come and learn to make noises in Pure Data with me! Should be a fun afternoon.

https://www.eventbrite.co.uk/e/introduction-to-pure-data-with-yann-seznec-tickets-63471063660

I'm going through old threads of mine and realising I never came back with an update to this.

In a nutshell, the answer to my question is that in order for the zexy "date" object to get the date the Raspberry Pi either needs to be connected to a network or needs to have a Real Time Clock (RTC). These are very cheap:
https://thepihut.com/products/mini-rtc-module-for-raspberry-pi

You need to follow the instructions for getting the Pi to get the RTC calibrated and working, but I had success the first time around with these: https://thepihut.com/blogs/raspberry-pi-tutorials/17209332-adding-a-real-time-clock-to-your-raspberry-pi

With that up and running the zexy "date" object appears to work great even when the Pi isn't connected to a network.

I definitely don't mind sharing. Here's the code that I used to make the video:
https://github.com/yannseznec/Everything-you-love-demo

The concept is designed for a standalone instrument, which runs on a Bela board in a custom made container. The code for that is necessarily slightly different, but I'll post that too when the project is ready to be shown to the world.

A sound is slowly destroyed through the process of being played. This is a demonstration of one of the patches built for a project I'm working on called the Book of Knowledge of Impractical Musical Devices, which details three experimental interfaces designed in PD. This one is for an instrument called "Everything you love will one day be taken from you".
Enjoy!

two other things:

• the [send] and [receive] objects can only have one argument (with no spaces). So your [s seq key17] and [r seq key17] objects are really just functioning as [s seq] and [r seq]. I don't think this is making any difference in your patch now, but you could get confused in the future if you try and use a similar naming convention.

• also, to reinforce my previous advice regarding [expr], you're using an [expr] object when you really don't need one. coming from [r seq key17] and going into a toggle controlling a [spigot]. there is a dedicated operator object that does this same exact thing: [==]
  again, this doesn't really matter but it might help you understand how the patch is working better.

So I think this is what you're after?

Essentially it's the same as the previous screenshot, in the sense that it goes through the same set of calculations but in reverse, and then use that to set the slider after a short delay.

but to return to your last question - the part that's most important in terms of the snapping feature is the [set $1[ message, which is being sent to the [s $0-setselection] object. I'll mock up a possible solution for you in a second.

So my general feeling is that you might be getting a bit caught up on the [expr] object. It's a super powerful and useful object but it can also make things a bit opaque for beginners.

I would suggest breaking it apart so you have a better understanding of what's going on. For example, if you take the two [expr] objects that are taking the slider data and doing the main calculations, you can turn them into a series of operator objects that make everything a bit more clear (and also makes it a bit easier to adjust individual parameters).

I'd forgotten about Patchbox...I just gave it a try and it seems to work well. It has the auto midi connecting built-in, so my startup script doesn't need to include that.

I haven't noticed much of a difference in terms of audio performance, but even just the auto midi connection stuff makes it worth it!

OK well somehow I've fixed it, but I don't know how. I don't think it had anything to do with a sleep mode, or my patch at all. I have a sneaking suspicion that somehow my Raspi got set to require a password on startup? I thought I had set it to auto login, but I switched that again and it seemed to work, so I dunno!