Help! I think I'm generating too many strings.
3 per second = 10,800 after an hour. Honestly I don't know if this is too many, but it seems to be causing problems when left running for any length of time (say, started up at the beginning of the work day). Things like the application stalling for minutes at a time when you switch to it from another application, etc.
Anyway, it's this autonaming function I'd come up with - it takes various user settings and generates a unique name based on those settings. When the user decides to record audio, it can automatically save a settings file and an audio file based on that generated name.
But, like I said, it's making 3 unique strings per second when it's active - one for telling sfplay~ what to do, one for telling a coll object what to do, and one for UI display purposes.
I'd be grateful if someone could take a look at it, tell me if there's a simpler way of doing something like this - or some way of cleaning the symbol hash table (last I'd heard there wasn't, but that was in 2006).
If not... I'll probably just kill the feature entirely.
The included max5 patcher is sort of a demo of the autonaming setup - the patch that contains it is just far too big (and far too unorganized at the moment) to post here. The one here doesn't actually write any files, it just generates strings and displays them.
Quote: MuShoo wrote on Wed, 17 September 2008 03:03
----------------------------------------------------
> Anyway, it's this autonaming function I'd come up with - it takes various user settings and generates a unique name based on those settings. When the user decides to record audio, it can automatically save a settings file and an audio file based on that generated name.
How many of these strings do you actually need? It sounds like the string only gets used when the user records, so an obvious suggestion is only to generate the new string(s) when you need them?
That way you'd only be limited by the number of recordings that are made. So - put a bunch of zl regs above the sprintf(s), or pack the variables into a list and put them in one zl (unpacking them when they come out. Bang them all when the user clicks record - you can use just one of these to generate your basic name and then send the result into three more sfprintf(s) or prepends to generate your open/set/write variants and save duplicating all your sends and what not.
Course, if you're recording a new file once per second this won't work...
If you need display all the time, maybe display the symbols un-concatenated perhaps, or concatenate inside a jsui and use that directly for display (I think internally javascript can use strings that are not part of the max symbol lookup table)
That all being said I have a stopwatch patch that uses symbols, and generates a new symbol every 10ms - I've not had any trouble with that. I'd imagine I've run it for a good amount of time, and it must be generating 6,000 symbols every 10 mins...
Mind you that might not be a very good idea either...
Regards,
Alex
Quote: AlexHarker wrote on Wed, 17 September 2008 03:32
----------------------------------------------------
>
> > Bang them all when the user clicks record - you can use just one of these to generate your basic name and then send .....
Sorry I edited that and didn't do it properly, so it's a bit unclear.
I mean bang all the zls (or just the one, if you've packed everything together). I also mean you can generate your basic string using ONE sprintf, saving all the duplicated receives (not sends...), and then prepend open/write/set to it, or use further sprintfs if more complex variants are required, which might result in simpler code.
Alex
Quote: AlexHarker wrote on Wed, 17 September 2008 03:32
----------------------------------------------------
> it must be generating 6,000 symbols every 10 mins...
Whoops, again, edited only half of it..
That should be 6000 symbols every minute - 60,000 every ten minutes....
That's fine, but actually I can't swear I've ever run it for more than 15-20 minutes...
Alex