I would like to have a slider with a starting value/position at the 50% position, so for example if the slider range is 1 - 100, then the starting value and position would be 50. I have used a bang to a message to the slider to set the starting value.

bang
|
50(
|
slider

This works fine but requires manual input on my part to set the value of the slider by clicking the bang button. I would prefer have this happen automatically, essentially reset the patch user interface controls to defaults when I run the patch. I tried an abstraction and use loadbang to trigger this routine

abstraction
loadbang
|
50(
|
outlet
end of abstraction
|
slider - main patch

But this did not output anything when the main patch runs.

how would I get something to run automatically in the main patch when the patch executes?

It looks like my abstraction is working correctly. I needed to close the patch and reopen. When I reopen the main patch, the slider is at the default 50 position or whatever I set in the abstraction.

Is there a way to get the user interface to reset from re-running the patch instead of re-opening the patch?

@hp3 What do you mean by "re-running the patch" rather than "re-opening"?
Patches are executing all the time..... they do not "run" as with other programs.
[loadbang] only bangs once as the patch is loaded.
You could put a bang in the main patch and use [send reset] and then [receive reset] in the abstraction to bang the [50( message....... that would reset the fader.
David.

By "re-run" I meant unchecking edit mode from the Edit window.
By "re-opening" I meant close the patch from the File menu, then use the File menu to open the patch.

When I "re-open" the patch the abstraction sets the default values for the ui elements as I intend. But I have to close and re-open the patch file to acheive this automatic reset. I would like to achieve this when I uncheck Edit mode.

Alternatively, I am using your suggestion of a bang to the abstraction and also a loadbang in the abstraction to output the default values to multiple sliders.

My eventual goal is to have about 10 sliders and other ui elements to transmit midi parameters to a hardware synth. I want to have default values for all of the ui elements and an easy way to reset the ui to its default values after I have used the interface.

My current approach uses an abstraction to send a default/starting value to an outlet for each ui element. The sending of this value is triggered by either loadbang in the abstraction or a bang button in the main patch.

Is this the preferred approach? There may be 10 outlets in the abstraction.

By the way what the purpose of the Init/No Init button in the Slider properties window?

@hp3 There is no reason not to do it that way.
You did not absolutely need an abstraction..... a sub-patch would do the same and be a part of the same patch file.
You could use arguments for your abstraction that set the values.... eg...... [kldefaults 50 1 0] which with $ values inside the abstraction would allow you to easily change the fixed values later.
You will find out as your patch develops what are the best options.

Selecting "Init" will save the last values of the slider (if you save the patch) and send them out as the patch is re-opened....... but of course in your case the loadbang will overwrite that again.
Useful if you want a value to return to its previous state.
Some objects actually say "save" rather than "init".

The patch is always "live" or "running" whether in edit mode or not. Edit mode lets you put and remove objects and edit their names...... while non-edit..... run mode as you say..... lets the mouse actually click objects and move sliders so as to send data.
David.

@hp3 As David already mentioned, the probably simplest way to do this without any abstraction is using sends and receives:

Instead of send/receive objects you can also use the internal send/receive functions of bangs. You can also combine them.

Any event can trigger the bang that resets all the interface elements, but to my knowledge there is no event when you exit edit mode.

If you don't want the interface elements to output their values when they are reset you can use a set message:

Demo: send-demo.pd

thanks for all the suggestions. I was able to implement the send and receive technique, that seems to work well in my situation.

However, I am noticing that when I use the bang to reset the values of the user interface, even though pd is sending out the correct midi messages for each ui element, the hardware synthesizer is not responding to the midi messages except for the last message received which would correspond to the radio button (right most control).

Is this due to midi sysex messages being sent too quickly for the synthesizer to process and it only process the last message? Is there a way to put a delay time in between the messages?

@hp3 You can try this using [delay] after the receive, but the reason may be something else.

@hp3 If @ingox has finished writing his tutorial it might be time to post your patch......
Use the bar with the up arrow to upload it and then we can spot any errors much more easily.
Sometimes it is a question of the order of operations....... http://puredata.info/docs/manuals/pd/x2.htm sometimes not.
A complete sysex message needs to be built for every piece of data....... probably order of operations problem...... timing problem doubtful.
Except in that the order things are done is a (sort of) timing issue..... (tying myself in knots...!)
David.

ok, here is the main patch

k1 controls.pd

and here is the abstraction that generates the sysex
k1sx.pd

All of this works fine if I operate one control at a time, but if I click the bang, the ui elements update and the midi messages print out correctly but the only parameter that changes on the hardware synth is the one corresponding to the rightmost control.

@hp3 I need to finish cooking dinner....... @ingox will beat me to it.....

In the meantime...... yes, it could be timing...... https://kawaik1.wordpress.com/2016/04/03/how-to-send-sysex-data-to-the-kawai-k1/
They say 10ms is enough....... between messages probably.
David.

thanks for all the help. I am very new to Pure data. I am not sure how to set up the delay. Are there any examples or tutorials that I might refer to?

@hp3 This will delay the messages when you reset...... k1.zip
Although I noticed that you had drawn connections to both the number messages and the guis from [r reset] for both speed and shape, which meant that the message was sent twice for those.
So if speed and shape are a "toggle" in the K1 the reset would have turned them "on" and then immediately "off"....... I don't know if that was the problem though.
David.