DSP Robotics Support

Roxy, you're confusing audio and application development. Sample and hold is well defined and has nothing to do with the programming, RJ is looking for. It is not even in the audio realm.

Hi Guys. Obvious APPRECIATION for all comments, insight, educating.

Given the fact that I'm not a programmer, only using FS when a crazy idea happens that I try to realize, Your
patience/tolerance helps me keep a positive attitude to continue trying.

To that ... I read each and every post made throughout this forum [minus the spam]. Whether it is anything I
understand or need to, is in-material. Sometimes the conversation/thought process can be just as valuable.

Last night I got to thinking about the PRESET MANAGER, and the various forum topics.

In the attempt to best simplify for the User, I wanted to avoid having to select a save/load destination paths for each
time this plugin was used, in however many projects [and I have a lot of them].

Dropping in a stock PreSet Manager, I pulled in the Parameter STRING prim, set it up, and fed it the Seconds-Count values. This was then tied to KG's counter he posted.

VST exported and tested in REAPER. The Saved, ELAPSED value was recall exactly as expected when re-loading the
project. I saved several different test projects ... each properly recalled the saved state values.

This is exactly what I was looking for.

If all is good ... then I need to look deeper into what PreSet Manager is doing. In particular, WHERE is he storing
the preset file. I've tried to view any File PATHs [tapping on a String prim], but they are showing 'blank'. I know it
has to be somewhere ?!?

Regardless ... and a key objective. Where the PreSet file is, is ONLY important to the plugin. I don't want any User
having to think about any of that, as long as the DAW pulls up the correct data for each project. [which it seems
to be doing].

So the question. Is the stock Preset Manager saving its file in a 'safe place' ? Where might that be ?? If so ... can I
just leave well enough alone ?!?

I'd be glad to post the schematic if anyone interested. I would like to test this further before that ... along with some
minor clean-up.

that's where we be at the moment ... now going for 2nd cup of Joe
[again ... thanks to you Guys. Nobody in my immediate circle has a clue about any of what this stuff is or does].
thanks.

tulamide wrote:Roxy, you're confusing audio and application development. Sample and hold is well defined and has nothing to do with the programming, RJ is looking for. It is not even in the audio realm.

[color=#FF4000]The way RJ described it brought me back decades when i was studying computer science with Tanel Demiray, from the University of Wales. We considered any data acquisition and storage as Sample and Hold.
I remember programming Sample and Hold examples in BASIC.
Data is data, an analogue signal sampled or population densities sampled.
Here's what I'm talking about....
https://www.mccdaq.com/handbook/chapt_3.aspx
Just trying to help....

ROXY ;[/color]

Hi ROXY.

One of my earlier experiments for this project was to, indeed, test the possibility of using S/H to
'freeze' the counter value. What I found ... it'll work within the FS environment, but once exported ... no.

As 'T' points out ... the data must be stored to disk.

From very early conversations, dating back to the SM days, it was described that exported SM/FS were contained
in a special SM/FS shell. This lead to thinking that the 'data' would 'stay' due to this shell.

Anyway ... what is cool about 'other' ideas are what they may influence to other techniques ... if only in concept.

It's one of the reasons I'm attracted to FS. The possibility to try to construct a solution for a desired task.

I'm in session later today, and will further test the new plugin.

rocknrollkat wrote:

tulamide wrote:Roxy, you're confusing audio and application development. Sample and hold is well defined and has nothing to do with the programming, RJ is looking for. It is not even in the audio realm.

[color=#FF4000]The way RJ described it brought me back decades when i was studying computer science with Tanel Demiray, from the University of Wales. We considered any data acquisition and storage as Sample and Hold.
I remember programming Sample and Hold examples in BASIC.
Data is data, an analogue signal sampled or population densities sampled.
Here's what I'm talking about....
https://www.mccdaq.com/handbook/chapt_3.aspx
Just trying to help....

ROXY ;[/color]

I know you're trying to help. And that's fine. However, it still is not applicable. You are thinking in terms DSP, not in general programming. Sample and hold specifically is not the right approach for storing data on disc between sessions. It just has nothing to do with it. I can't explain it any better. Whatever you considered as Sample and Hold, it is well-defined, and it is not up to us to assume what you consider calling something. Instead you only confuse people that read here, because the issue we're talking about is not signal processing. Also, "data is data" proves wrong, since it is dependend on the environment.. You simply can't handle audio data like you can handle text data. And you can't handle graphic data like you can handle audio data. Etc.

I don't want to derail this thread. Can't you just accept that you although trying, you didn't help? It doesn't make you a bad person. And it is no shame either.

[quote="RJHollins"]Hi ROXY.

One of my earlier experiments for this project was to, indeed, test the possibility of using S/H to
'freeze' the counter value. What I found ... it'll work within the FS environment, but once exported ... no.

As 'T' points out ... the data must be stored to disk.

From very early conversations, dating back to the SM days, it was described that exported SM/FS were contained
in a special SM/FS shell. This lead to thinking that the 'data' would 'stay' due to this shell.

Anyway ... what is cool about 'other' ideas are what they may influence to other techniques ... if only in concept.

It's one of the reasons I'm attracted to FS. The possibility to try to construct a solution for a desired task.

I'm in session later today, and will further test the new plugin.

Hi RJ !
Interesting that you were considering Sample and Hold as well !
I was just read the riot act about how this is NOT S%H, Wiki and T say so, I guess we're BOTH wrong !
Anyway, I won't be coming around any more, but I'll be lurking.
If you need me, just holler, I'll be there !
Your pal,

ROXY

tulamide wrote:

rocknrollkat wrote:

tulamide wrote:Roxy, you're confusing audio and application development. Sample and hold is well defined and has nothing to do with the programming, RJ is looking for. It is not even in the audio realm.

[color=#FF4000]The way RJ described it brought me back decades when i was studying computer science with Tanel Demiray, from the University of Wales. We considered any data acquisition and storage as Sample and Hold.
I remember programming Sample and Hold examples in BASIC.
Data is data, an analogue signal sampled or population densities sampled.
Here's what I'm talking about....
https://www.mccdaq.com/handbook/chapt_3.aspx
Just trying to help....

ROXY ;[/color]

I know you're trying to help. And that's fine. However, it still is not applicable. You are thinking in terms DSP, not in general programming. Sample and hold specifically is not the right approach for storing data on disc between sessions. It just has nothing to do with it. I can't explain it any better. Whatever you considered as Sample and Hold, it is well-defined, and it is not up to us to assume what you consider calling something. Instead you only confuse people that read here, because the issue we're talking about is not signal processing. Also, "data is data" proves wrong, since it is dependend on the environment.. You simply can't handle audio data like you can handle text data. And you can't handle graphic data like you can handle audio data. Etc.

I don't want to derail this thread. Can't you just accept that you although trying, you didn't help? It doesn't make you a bad person. And it is no shame either.[/quote


From RJ's original post....
If anyone can guide me, the objective is:

1. A trigger or Boolean to start/stop the counter.
2. internally save the last counter value [do I need to right to a file ??? hope not ... but]
3. start app to count from this 'last saved' value.
4. option to RESET counter to ZERO.

No mention of where the data is stored.
No mention of the data 'class' (audio, video, population count, etc.)
No mention of what 'realm'.
Wiki gives the common, modern definition of S&H, believe me, I checked before I posted.
And in the digital environment, ALL data is ones and zeros.
I call it what I was taught, not what I 'assume' it is.
I gave you a link to the overall concept of data handling.

I see what's happening here.
I'm the new guy.
You're all well established, you have the pecking order in place.
I come to the table with well over 60 years of experience in electronics, music, entertainment industry, etc., thinking I could share it all before I die.
But I'm ruffling feathers and stepping on toes.
I'm being 'corrected' on topics that I know from those decades of experience.
My time would be better spent building application specific plugins and composing music, rather than defending myself every time I try to help someone.
I've been blessed with having been born and raised in the entertainment industry (both parents and relatives), been involved all of my life, and now it's time to give it all away.
Sorry I 'confuse' people.
Adam started this trend, "Sorry, but you're WRONG", and it's picking up steam.

I'll be on the boards 'lurking', but expect no more from me unless someone specifically asks for my help.

Sorry it had to come to this.

ROXY, the "Dead Simple" guy

You have a serious issue, mate. You fight each and everyone who's not cheering you. Always drama queen then. Do you really not understand? Every second sentence is about what awesome guy you are, how talented, how gifted, how unique. It's almost narcissistic. But the people on here are at least on par with you. They just don't brag about it. You wouldn't be able to compete with Martin, KG, MyCo, TheOm and others. But they don't claim praise from people, and they admit errors.

Sorry, but I'm glad if you keep your word (although I'm sure you won't).

rocknrollkat wrote:

RJHollins wrote:Interesting that you were considering Sample and Hold as well !
I was just read the riot act about how this is NOT S%H, Wiki and T say so, I guess we're BOTH wrong !
Anyway, I won't be coming around any more, but I'll be lurking.
If you need me, just holler, I'll be there !
Your pal,

ROXY [/color]

Yeah ... I understand. And I think a bit over the top to call for a riot about it.

To FlowStone. We do have a prim called Sample/Hold. Have used it before. A very handy piece when building
a puzzle [object] schematic in FS.

Without giving 'riot cause', my previous post of SM/FS being the shell for any exported EXE or VST was in hope
that the 'environment' would have similar reaction as we have when working in FS proper.

I GET IT now. I also know I'm not the first, nor last of a new user wondering/trying the same.

My only 'programming' experience came during the ATARI 1040 daze, and something called GFABasic. I even developed
an application that handled Studio Management of client booking times, scheduling, mail-outs, etc. During THOSE
days, there was nothing for a studio business. [I even made a few bucks].

NOW ... I'm hear to learn a bit, and have some fun putting together an idea that might be useful to my work. That,
and follow the other threads to see what others are working on.

I've been running my little PlayTime app for the past 4 hours. It still running.

I do have an area or two of 'question marks' ...

But what I'd like to do is isolate the module from my workspace schematic, and post it here. Maybe then I can get
some feedback or advice ... and possibly some insight to question.

Always. Thanks Guys

OK. Here be v: 0.1 of my PLAYTIME plugin.

The goal: To have a plugin that tracks the amount of time that a DAW is in PLAY mode.

As a project is being worked over the course of a day, week, or year .... to have a reference to the actual time
the track has been played during the whole time.

The OPTIONS are quite minimal at this stage, as I hope this core is solid, reliable. There are some other options
that may go in next.

Anyway ... thanks to the FS Gang for things even outside this specific project.

Special thanks to KG for providing a 'Counter with data re-entry' that proved essential. THX !

Here's the v: 0.1 schematic.



note: there are a couple of question areas that someone might help on ... but I'll wait first on comments.

Thank-You.
RJHollins