Collection of Anonymous Statistics on usage of Engines?

Software
1

I know that collection of data can be controversial, but, I just want to put forward the idea of an opt-in, anonymized collection of what sound engines or effects or whatever people are using the most often, and some of the, I think they’d call it telemetry? Anyways, how well they work, CPU/RAM usage, etc.

Being that people are presumably composing original music on these devices, there would need to be very clearly defined boundaries of what data is collected, with all user content behind a hard firewall of zero collection. I’m talking strictly about observing how the devices are being used, with a strong focus on what is working well, what is popular but not working that well yet, and what is both unpopular and not working well, and perhaps could/should be removed from the system, or at least set to uninstalled-by-default status.

On July 1, I shifted from owning a Zynthian primarily for ideological reasons, to actually using it for stagebound music. My APC Key25 arrived a couple days ago cause that Launchpad Mk1 turned my Electric Avenue parody into a total trainwreck, and the APC is clearly going to be the canonical OTS midi controller for the foreseeable future. The work you guys have done on that driver is just amazing, I am blown the heck away.

Its only downfall is the weaksauce LEDs; When I got it, I setup on the deck cause it was a nice morning, and while the pads being lit up only where I had pattern loaded delighted me to my very soul, they were basically just a vague suggestion of colour in the bright sun. A simple three-colour mode (loaded, stopped, playing), with the colours themselves chosen for the highest visibility in full sun, would not be a terrible feature. But I digress.

Anyways, I was trying to get a chiptune feel at first, and rather than finding a soundfont, I initially added a SID emu engine that is not installed by default, and when I kicked that pad in, the machine locked up. This was on the Vangelis build, I switched back to Oram for the moment after this happened consistently (I have the Snapshot file that caused that lockup on Vangelis, been meaning to send it along to the github for analysis, will try to get it off today, sorry, I don’t need it fixed but I’m sure it would be useful insight)

Anyways, my point being, that might have been Vangelis (I was warned, after all) or it might have been that obscure little chiptune engine of indeterminate dev support, and basically, it would be extremely useful to every one of us, if we could know, from real world usage statistics that we voluntarily share, what things are working well, what things are working best, and what things we should pass over, on any given day, if we want to be making music and not fighting Linux.

I like fighting Linux and I like making music, but some days, I want to do only one or the other; the Kitchen Sink approach to user options might not be the best way to go, if we want to attract more people who only like to make music, and do not care to know a thing about Linux, to the project.

I know that Linux Zynthian For Keyboards (I think that was the announced name) kind of tries to address this a bit, and I look forward to checking out that new thing, when it’s ready. But having the real world usage data from people who are using these out in the world would be invaluable to us all.

Something for everyone to consider, and comment on, if it was ever to have a hope of happening - I suspect it will only get any sort of traction if people in here think it’s a good idea, and say so.

4 Likes
2

It’s a good idea I reckon. For someone like me who never had any experience with Linux audio and plugins it’ll help a lot. I learn on the run though - trying different engines and effects but everyone’s setup is different and what could work for some may not work for ohters I guess, still I would be curious to see what experinced users work with.

3

Its an interesting idea to use telemetry to track useage patterns. However, i think in such a case there need to be some opt-out choice to be made by the users.

Example: I run my Zynthian connected to RJ45 (to drive rtpMidi from my DAW). I would literally hate to see this fact being used by Zynthian to (always/as i use it) sneak out useage data through my ISP to some dark place on the Internet, without me knowing about it.

However, if it was possible to:

  • ackumulate metric data locally
  • enable the user to browse and approve what is sent out (perhaps manually)

i would have no issues with it.

4

I think opt-in is the best approach. I doubt very many people would have a problem with it, but it should be 100% voluntary imo. Inherently auditable because of what this project is.

But imagine, you’re twiddling through the options, and as you go, it tells you “this is used by 90% of users” vs 50% or 5%. Very useful information no matter what.

5

Sounds like an attempting idea. It should be opt-in, if at all.

But on the other side, the individual Zynthian engine must be trackable if you want usage reports of different Zynthian engines. If you don’t use some kind of unique tracking number, the result is just random. I could replace lv2 A and lv2 B several times and the ranking would go up and IMO there would be no real information about useful uses of these lv2 plugins.

Also, if you don’t know what is the scenario a plugin is used (mixing, guitar pedal, synthesizer, music writing), the usage information of plugins alone are quite senseless.

And because I’m always for keeping software as clean as possible in the sense of data spreading, I would not opt-in.

I would more likely vote for a browseable library of plugins together with examples to get an impression of what these plugins are able to do. Or a browseable example library of whole setups, just to learn from others how they are using Zynthian. And this is already possible with the snapshot saving.

Just my 2cents..

Regards

6

Perhaps when people upload their music examples, either for gratitude due or for whatever reason, they could optionally include in addition to the audio, the snapshot (.zss) used to produce it - like the entries in the contest for the win a Zynthian V5 upon its release:

7

I can’t imagine why I’d want details of what other engines people use in isolation. When I’m playing or composing I have an idea of what I want it to sound like and use the engine that provides that sound, or an approximation. Knowing “A lot of people use geokick!” when I’m putting together my lofi-plainchant-ambient-timpani tracks feels like a nonsense.

Let people make music without another technical overhead and free from needless privacy and security concerns. No-one needs to know this stuff other than to satisfy the incurably nosey, really.

7 Likes
8

Spicy!

9

We always rely on @Baggypants to tell us as it is. I agree that this is an overhead that provides little benefit. It feels like something that others have done so maybe we should do it because it may be beneficial, but in reality a ranking system based on recommendations is better, as is a way to find the thing you want rather than the thing everyone else is using. I am the antidote to fashion!

10

Love you! :face_blowing_a_kiss:

11

Is anyone working on that recommendation-based ranking system? Genuinely curious, cause the current kitchen-sink, zero opinion approach is a bit of a dog’s breakfast for anyone starting out with these engines - massive range of choices, no ranking or knowledge as to which is good at what. I do not lack knowledge of the different types of synthesis, but I still don’t have a go-to for a good Moog-like monosynth, for instance.

Anonymous usage collection would be a way to get a starting point, using empirical real world data, but I’m all for any sort of system for determining objective usefulness for a task, on some sort of hierarchy. Opinion is just as good as real data in this case, but at the moment there’s just a firehose of choices and zero opinion of any kind. It’s a problem, if you ask me.

I think that, as mentioned in OP, it is useful to know which engines are stable and do not tend to crash, as well as which ones the opposite is true, as a baseline reason for collecting this data, with an objective view of actual popularity (as opposed to random collected words, which as anyone who’s been on the internet for a year knows, people absolutely love to provide opinions, whether they have useful experience or not. And now you have a legion of flesh proxies for AI, so I have less and less confidence in the opinions and recommendations of the internet these days.

There is a reason that when you install Debian, you are given the option to participate in the package survey. I always answer yes, because it helps them to make a better product.

That said, the cheerleading for the aggressive zombie retort with personal digs is noted.

3 Likes
12

Knowing that 100 people followed the same (intuitive or most likely) route to select the same engine doesn’t give us any useful metric.

We already curate the “best” engines based on opinion and functionality by enabling them by default. All of those also have a description and ranking. There is the star rating which is mostly done by the devs based on user feedback and there is the knobs rating of complexity which is basically an indication of how many parameters the engine has.

It would be good to have better reviews of engines and a popularity rating that users could vote on, but it is also horses for courses. As @Baggypants says, knowing the dexed engine is very popular doesn’t help me choose a harp sounds for my orchestral piece.

There is currently not an active rating participation scheme. Someone here could suggest a framework for that to give meaningful output with achievable engagement.

13

If 100 people chose one engine, and only 10 chose another, and 1 chose the other three, and all were nominally the same class of sonic generation (FM vs. Additive vs. Mono vs Poly etc)… I’d find that knowledge useful. If I also knew that was because the 100 people was due to instability, that would also be useful.

We disagree on this and that’s fine - this is not my project, and I am not a main dev, so this thread was dead for 29 days, and forgotten on this end.

But again, the fact that both main devs replied in the affirmative to a post that is basically just derision is the main thing I’m getting from this interaction.

14

Hi @jtode and others !

My 2 cents …

I understand your proposal and believe me, i have thought really a lot about all this from a long time ago. But at the end, i always reach the same point, that is more or less the point that @Baggypants expressed in the raw way. And here we are entering an arena that is close to philosophy and dangerously close to political mindset … what we always try to avoid :grin:

The questions is:

  • some people believe knowing what the other people does can be useful for them. They put in the balance the pros and the cons and pros win.

  • in the other hand, some people think that knowing what other people does is not useful enough and after putting in the balance the pros and the cons, the cons win.

Of course, when i say “other people”, i mean “unknown people”. If you could select the people, things change a lot, of course. Perhaps knowing the engines used by @Baggypants could be very interesting for me. Or perhaps we could have some metrics to know the engines preferred by european males from 30 to 50, etc. This is tempting, and the separation between “other people” and “known people” can be blurred easily. When you start collecting data, a new world of possibilities open in front of your fingers, right?

To add more ingredients to this salad, the list of “cons” include some subjects really “difficult to manage” regarding privacy and security, with legal implications, etc. Collecting data is regulated by law…

Not an easy salad …

1 Like
15

I certainly don’t mean to derisive, far from it. The idea is often considered but in its raw form as suggested, it doesn’t work. Just because 100 people used an engine we don’t learn if they found it useful or problematic. Pure access to something only tells you that someone accessed it, not why or what their experience was. That is why I suggested that metrics may be useful if there is some metadata and that requires someone to design a framework. Pure usage metrics are of very limited benefit with substantial effort to collect and collate. It is plausible that most casual users may be connected to the internet (with ability to contribute data) and most serious users are not. Such a scenario completely skews any data.

By all means suggest a framework that provides specific benefits and it will be considered but as told by @jofemodo, our previous consideration of this has led us to decide it fails the cost/benefit analysis.

2 Likes
16

Since you guys are responding, I’ll keep responding, and in this case, everything you just said is addressed by making it opt-in. That’s all I gotta say about that.

17

As I said, I consider the matter closed as of about 28 days ago. It was revived by an aggressive post and then both of you decided to join in, in support of what I consider a rude post.

I expect no apologies or anything from him, I gave a one-word reply and went back to my completely woodworking- and gardening-related day. But if I am offering a critique of anything, it’s your overt endorsement of, again, a response that offers nothing but spicy opinions. That’s not good community management.

Almost done my herbal break, back to the table saw in a moment, and I will do my best to forget this thread existed, again. Unless someone else feels the need to keep it going. I have said all that I need to say.

edit just to say: I would happily participate in desiging and implementing this system, and I believe it would cost close enough to zero system resources as to be the same thing. But the community, as I said, has spoken, and I moved on weeks ago, untill the thread came back.

1 Like
18

Hi @jtode!

Please, don’t feel upset. People have different points of view and it’s perfectly OK. Some like to express his POVs in a “raw” way, and this should be OK too. I don’t think this is disrespectful and nobody should feel upset because of this. Sometimes it’s refreshing and healthy to say things as you feel It … it’s a pity we don’t (can’t?) do It more.

LOVE!

19

While we’re already talking: I actually really want to know what engines other people use. Surely knowing what monophonic synth @Baggypants use doesn’t help me to chose a delay engine, but knowing what delay engines @Baggypants used helps me to chose a delay engine.

That said, I wouldn’t necessarily want to get that data by constantly collecting uset data, even not opt in, also for the reasons already mentioned. But there are other ways, including:

  • starting a thread here where evenyone can propose the three favorite engine of each category, and why this is it
  • Binding the quality and complexity ratings to active user interaction, including the opportunity to give textual feedback (as in “submission form” inside UI and/or webconf)
  • Having an external engine database to provide this data actively.
3 Likes
21

Anyone wants to chime in?

3 Likes