Hey everyone,
I wonder if it’s possible to keep the MD Slider input data in some way.
I give a point from a list new coordinates via a MD Slider, when I switch the point of the list, I want the choosen point to keep with his last coordinates even after switching the points. Maybe someone knows a solution for this?
Thanks in advance!!!
You didn’t internalize your Crv geometry. Your description isn’t clear to me either?
P.S. It appears that your MD Slider doesn’t use the default ‘0 to 1’ domain.
My bad! I include here the file with the internalized curve.
The thing I want to do is to move each point of the InterpolatedCruve with one MD Slider. There for my first step was to make it possible to switch the points by replacing them on a list. The replaced point gets his new coordinates from the MD Slider, but doesn’t keep the updated coordinates, when I switch to the next point. Now I am locking for a solution how to safe the MD Slider data for one point, so it stays where it is and I can do the same with the next point and so on. Its like moving points of a curve in Rhino.
I hope it’s a bit clearer now, thanks for the reply anyway!
last coordinates file Internalized.gh (21.0 KB)
Hi,
This is not how Grasshopper is supposed to work. In your case you should have as many MD sliders as the amount of points you want to change.
Or, a generic rule to move them all at once.
You may be able to use Data Recorder to store the points once they are defined.
Move your MD, when you are satisfied plug it into a Data Recorder. Then unplug it.
Rinse and repeat until all your points are set.
For one thing, it sounds like you want to choose from a list of points and have the MD Slider updated with the chosen point? Then when you move the MD Slider, the new location replaces the previous one in the list of points.
Not with standard components, as far as I know, but perhaps with a plugin or C# or Python.
You could replace the MD Slider with a pair of conventional sliders, of course (X & Y).
This interests me because I had a very similar idea years ago when I started using Grasshopper… It’s a worthy goal.
So I just installed metahopper (Sacré bleu, me using a plugin!!) and played around a little bit. I am able to initialize the MD Slider using the ‘Choose’ slider when in “Choose mode” (blue group) and then move the selected point around using MD Slider in “Move mode” (blue group again). But it falls apart with a “cyclic data stream” error when I try to save / use the moved point.
I hope someone can solve this, the general idea makes sense and would be useful.
P.S. I just found a possible work-around, though it looks messy:
This dirty double data dam trick (gets round GH’s restriction on cyclic data streams without plugins) can be fun to play with, but isn’t really recommended for anything serious, and is likely to cause crashes - use at your own risk!
– Daniel Piker
Thanks to @DanielPiker’s “dirty double data dam trick” (“naughty loop” in red group), this is weird but seems to work! Though it is cumbersome…
INSTRUCTIONS:
Set Value List (blue group) to “Choose” and use the ‘Choose’ slider to select one point.
Set Value List (blue group) to “Move” and use the MD Slider to move the selected point.
The reason for the Value List switch is to suspend metahopper from resetting the MD Slider so it can be moved.
As I recall, the similar idea I had years ago (on the old grasshopper3d.com forum) was a way to index saved states of a cluster. It could have any number of inputs (like sliders, rotate angles, value lists, etc.) and when the index value is changed, the control inputs would be reset to the saved state values. 
UPDATE: Two minor cosmetic additions:
In the process, I noticed that points 0 and 8 are duplicates.
This is amazing, I am still following your construction path here, trying to understand what is exactly happening. In anyway great help!
I will also give magicteddy’s data recorder approach a try.
Thank you some you too!!!
P.S.: The index save state was also my first thought, to kinda create text files for every point where the last save can be stored and picked up again.
You should do that more often. This is incredible ! 
I believe the Value List switch could be removed if I could write a Python function that:
Can anyone provide that code? I’ve tried a variety of methods but all fail. Example:
import time
a = True
time.sleep(0.333)
a = False
I’ve successfully used metahopper to set the range of the ‘Choose’ slider to the number of points, which eliminates one source of error. Dropping the Value List switch and the “naughty loop” would go a long way toward making this a fine piece of code.
Hi,
You need to schedule a new solution.
ScheduleSolution.gh (5.7 KB)
private void RunScript(object x, ref object A)
{
if (firstrun)
{
GrasshopperDocument.ScheduleSolution(1000, CallBack);
firstrun = false;
}
else
{
firstrun = true;
}
A = firstrun;
}
// <Custom additional code>
bool firstrun = true;
private void CallBack(GH_Document sender)
{
this.Component.ExpireSolution(true);
}
Thanks, I did try several variations of “schedule” (in Python) but, despite extensive searching, I don’t know what I’m doing.
This C# code works the opposite of what I need and my attempts to modify it fail, unless I reverse the output: (I suppose I could do that internal to the C# instead of externally)
LATER: Forget that, either way can work for me!
.
I don’t see any way to set the delay?
A = !firstrun;
That’s the first argument in ScheduleSolution(), in milliseconds.
Of course! Thank you very much. Seems to work most of the time but IntCrv fails at times without any error message… 
Too fragile for my taste but OK to test a concept. Moving the ‘Choose’ slider quickly causes the failure.
MODIFIED INSTRUCTIONS:
Two hours, and I won’t mention the amount of Rhino crashes due to infinite loops 
It doesn’t work for polylines though
I really wonder how this could reasonably be part of a decent GH workflow. It’s just easier to move the CPs in Rhino…
MovePoints.gh (13.4 KB)
Yeah, but C# doesn’t do much for me unless it’s extremely simple. I see you are setting the MD Slider without metahopper, which is cool, but you always center it, which isn’t quite as cool as what I posted… Impressive in a way but I won’t spend much time understanding the C#.
I’ve spent a lot of time (stabbing in the dark) trying to replace the “dirty double data dam naughty loop trick” with a pair of simple Python components, which will probably horrify anyone who knows better: sPts (Save Points) and rPts (Read Points)
Save Points:
import rhinoscriptsyntax as rs
import scriptcontext as sc
unique_counter_key = "savePts_v0"
print unique_counter_key
print P
sc.sticky[unique_counter_key] = P #save value for next loop
Read Points
import scriptcontext as sc
P = []
unique_counter_key = "savePts_v0"
if sc.sticky.has_key(unique_counter_key): #retieve value from last loop
P = sc.sticky[unique_counter_key]
else:
P = "NO!"
print P
Amazing you got around the naughty loop, this is really great!!! Today I had time to look at the stuff you guys posted.
I really like how the choose slider is limited to a range by an expression!
I removed the duplicated point we had at the beginging by using a domain for the coordinate list (marked blue)
I add something to your last file and I have another question:
I put the controlpoints (now modifyable by some MD Sliders) back into the replace items component (marked green) to make the curve adjustable with all the MD Sliders.
Now the coordinate data isn’t stored anymore and the points are jumping back after I chose another one. Maybe you guys have an idea how to incorporate my new adjustments?
Looks like you broke it? Pottery Barn Rule applies - you break it, you own it. 
Hahah 
I guess so, but still, I hope you like what I did there
Break it? No, I don’t like that. What good is a broken tool?
But it was fragile before you touched it, too easily broken.
