It should be possible to make Curves global

[Hartinger]

Currently, curves in ETHOS are always model specific. However, there are quite some cases where the same curve is needed for a number of models, which currently requires multiple definition of the same curve in all affected models. It would be a significant enhancement if curves could be made global by addition of a corresponding "Global" flag (similar to the Special Functions). Just one example: Every glider using the Butterfly mix requires a curve tranforming the signal from the throttle stick into the 0 ... 100% input required for the Butterfly mix.

As the definition of a curve is completely independent of any other model specific settings, they really lend themselves to being made global if necessary.

[EngelMT]

I fully agree with this. This would be a very useful change.

[EngelMT]

And please can you a add real library which can be used by all models?

In the moment we dicuss in our forum about a real good solution. We will let you know if we have good ideas.

[PD5DJ]

Would indeed be a nice idea, to create a library for curves.

Now global is so definite i every other model, therefore for now i dont use them. Library functions could be interested for many things inside the Ethos system.. also for specific multiple function switches that work cohesive.. Like resetting telemetry functions with play tracks that we are usually have the same for every model.. but not want in every model.

[bsongis-frsky]

Now global is so definite i every other model, therefore for now i dont use them.

I don't get your meaning

[PD5DJ]

Well if I set a special function in model 1 global.. it is directly available in every other model.. I dont want that. at least not for every model. And if i delete this function in the model where i dont want it to be.. it is gone everywhere.. this is what i mean with "definite" I really know this feature can be very usefull but must be thinked over.

Idea could be that you can set a Group ID for a function/SF/Curves,, this way you can group functions/specials functions and curves

[EngelMT]

This is indeed a problem. One must have the possibility to set for which model the function should be global. For example, I might want a butterfly curve to be global in my gliders because I always use it the same way and change it the same way. But in a gasoline powered model I don't want these changes.

Therefore a library would be optimal in which I can store the curves in a folder "global curves" and a folder "local curves". The global curves can only be edited in the library and affect all models in which I have inserted this curve as global. The local curves can only be inserted from the library into the model and can also only be changed in the model.

[EngelMT]

To give an ID to the curves is an interested idea too. So the customer can decide witch kurve is used for what models.

[hrenz]

Makes it much easier.

If you create a curve in the model, it can be used in the model, so far ok. But then you can also click that this curve will be added to the library as a copy, with its name.

If you need another curve you can select it from the library and it will be copied to the model. or create a new one only in the model.

The curve library can be edited, curves can be added or deleted, but the model does not care about this anymore because it uses a real copy of the curve from the library.

This curve in the model could now be adapted again for the model and then decide whether you want to include it in the library or not.

The danger of pure global curves is that if I change the curve in the library it changes everywhere, in all models that use this curve. This must be excluded and can no longer happen with the copying of the curve from the library into the model.

the curve library belongs in the system menu With a thumbnail of the curve it would be easy to recognize in the system menu. clever names also help

[Hartinger]

As Helle has already alluded to, the discussion in the Engel FrSky Forum has revealed some concerns regarding genuinely global curves. If any such curve is modified, then this will have a direct impact on all models using that curve. Moreover, this impact may not be immediately obvious, as curves can be used for a model in a number of different places throughout the menus.

The proposal is therefore to implement a curve library, which would expand the selection options for the generation of a new curve in a model. Each curve generated for a particular model from a member of the curve library would be local to that model, as per the current implementation. It would inherit the name of the curve in the library, which could then be changed as desired (without impacting the name of the curve in the library). In the event that a curve in a model is edited and adapted post its initial generation, this would be a pure local process, i.e. no impact on the curve library.

In order to incorporate new curves into the library, or to edit existing ones, there might be a special menu "Curve Library" (probably as part of the system menue). Alternatively, as explained by Helle, it should be possible to insert into the curve library any (local) curve available within any specific model.

[aalain8]

Hello, I'm very interested in a library of curves myself The two previous messages summarize the best choice for me. As well as the proposal of Hobby4life: create a library for special functions.

[koakumaping]

I fully agree with this. This would be a very useful change.

[mirko91]

I would say not only a curve library, but a library with special functions and logical switches as well. This will be a leap forward

[azaz44]

I would be interested in this too. But I would actually love to edit the curve in one place, and affect all models with it. This would be so useful.

The biggest problem I have while using Ethos (and OpenTX was no different in this regard), is that whenever I want to make some change, I most likely want to do this for all my models. I fly helicopters, have 7 of them, and all of them have same expos, curves, logical switches, special functions, mixes etc. Settings of the model are 95% the same.

But whatever I change - change some expo, curve, something in flight modes, invent some new logic with a bunch of LS - this has to be transferred to all other models. This makes a simple change take 2 hours of clicking. I don't even want to think how it would look like for 10+ models.

So anything that can be made "global" would save me a lot of time.

I realize this is complex in general, because all things reference other things, which don't exist on global levels. But with curves this would be possible, because they don't depend on anything else.

I would immediately define my expos in global curves and use them in all models. Changing expo for all models would be so easy then.

But yes, I understand that people who fly different types of models with one radio (gliders, helis, planes) would love to have some "groups". But please don't miss the opportunity to edit a curve in one place for multiple models. This is entirely different than "copying a curve from library" and very very useful.

[arshish1612]

I would say not only a curve library, but a library with special functions and logical switches as well. This will be a leap forward

Request along the similar lines raised here.... https://github.com/FrSkyRC/ETHOS-Feedback-Community/issues/2371

[Kreisflieger]

Still waiting for this enhancement. Are there more interested ? Then please add your comment to unstale.

[azaz44]

I'm interested, but for me this is a much bigger topic which involves way more than curves. So I think this is to be discussed when 1.5 is ironed out first.

[Kreisflieger]

Please open again. Still waiting for global curves ! Maybe for 1.6 ???

[strgaltdel]

I also support the idea of global curves.

A small note:

The concept of global objects (LSW / SF / Curves, etc.) has been discussed multiple times.

Depending on the context, for example, if a pilot flies different types of models (gliders, drones, jets...), there are different "preferred global setups." A LSW that’s needed for jets may be obsolete for drones.

As an idea or discussion basis:

(1) A kind of library management for different application areas would, in my opinion, be a preferred long-term goal.

Global objects (LSW, SF, Curves) could ideally be assigned to a specific application library (like glider, drones, jets) . In the model settings, it would optionally be noted which application library is valid for this model-memory. If a model has been assigned a library, the corresponding objects are automatically valid. a library contains sets of SF's, LSW's and curves

Changing this assignment would only be possible with a double confirmation and would delete all potentially dependent entries.

(2) Another idea would be that global objects like LSW or SF don’t necessarily have to be "active" or "functional" in the model memory. A global SF exists in all memories but could be activated individually.

Idea (2) as a discussion basis would certainly be easier to implement, but in my opinion, not as transparent or easy to understand for the standard user.

The main challenge will be ensuring compatibility when copying a model to other transmitters.

Transmitter A (source) doesn’t necessarily have the same global setups as Transmitter B (target).

What happens if the curve isn’t included in the target transmitter’s setup? What if SF’s or LSW’s don’t exist, etc.? Following the "Keep It Simple" approach, I would say:

Each "application library" (e.g., glider, jet, etc.) would have a checksum, which is transferred along with a model that is assigned to a library. If the library checksums differ between the source and target, an error message would appear: "Copying not possible, please align libraries." However, this would only be possible when copying models under Ethos.

Simple file copying is more difficult. In principle, it would work if the model memory always included a unique identifier (UID) of the transmitter under which the model was last used. The transmitter UID and the library’s checksum would allow a plausibility check on the "new target transmitter," since even with simple file copying, it could be detected that this is the first time the model has been opened on the current transmitter.

(I hope I explained myself clearly.)

Just some ideas for the long run, 2.x or so....

regards udo