Discussion about a List of Contributions Discussion

Apologies for not chiming in sooner, I am back from my travels and currently taking a brief break from grant writing as I face looming deadlines upon my return.

Given our previous conversation, I totally understand the preference for Leading Generators / Following Generators as the two primary categories. This is clearly more in line with the broader modular synthesis philosophy. So, I do appreciate them on those terms.

But not considering myself a deep synthesis head (though I thoroughly enjoy learning about it more and more, rabbit hole, etc) I personally find the terms you’ve chosen confusing/frustrating/minimal probably in the same way you felt about the previous categories. I personally preferred Voices / Effects / Utilities / M.I.S.C. as the categories. They are more in line with my personal approach in my studio and I would argue possibly more familiar and less opaque to the larger music making community of which eurorack modular is a member amongst many.

I guess it boils down to a question of broad appeal versus niche.

Or it’s too bad mediawiki doesn’t have a system for reordering page entries based upon tags, etc. so it would resort depending on the user’s preference. (I’m about to read an article about tables to see if that reveals any interesting options).

But, that’s just me. I am flattered to be asked for my input, but I am more than happy to defer to what the community on this forum prefers, though given the lovely cast of characters here I doubt there will ever be consensus. :joy:

The reality is there is now a centralized page that makes finding and downloading the user contributions substantially easier than previously regardless of how they are categorized, that’s all I really care about.

Excited to get back to couch mining and populating the list!

1 Like

i took the liberty and tried to add some entries to your experiment.
http://wiki.orthogonaldevices.com/index.php/ER-301/User_Contributed_Presets#Sandbox_-_Tables

1 Like

Thanks!

I just did the same and experimented with various table formatting options (For those paying attention I was randomly assigning ‘Type’ and ‘Generator’ values just for sorting proof of concept):

http://wiki.orthogonaldevices.com/index.php/ER-301/User_Contributed_Presets#Sandbox_-_Tables

I think in the end as much as I like the idea of a sortable table, there’s just too much data for each entry that it quickly becomes a formatting nightmare. The expanding description thing was chaos, so I removed it. Then there’s such a wide range in the width of peoples username, links, etc. And it means losing the edit button for each entry which will obviously prove to be super useful in the future as people update their contributions.

Unless someone with deeper Mediawiki skills than I can figure out something, I’m prepare to throw in the towel on that experiment.

I feel like time might be better spent debating alternative names to “Leading Generator” and “Following Generator”, they are opaque to me. How about “Signal Generator” and “Signal Processor”?

I still miss “Voice / Effect / Utility / Misc” though, they feel more transparent to me. And some credit to the fact that the “Voices” category triggered this whole crazy endeavour, haha. But it’s not a hill I need to die on, I good with whatever we come up with. :slightly_smiling_face:

1 Like

@iiii please, don’t give up the table experiment (yet), i will present some suggestions that might ease some of the pain… (on the other hand i had also some worries you didn’t mention)

meanwhile i’d like to learn more about how and why you (all) would find those names problematic.
(i realize that traditional concepts would be more familiar to people, especially when you come from a background of e.g. electric guitar rigs (like i did).)

did you find the explanation i gave on the wiki page also problematic? also, if you got ideas how we could improve names and explanations: please, let me know! i’d like to follow that path for my personal understanding even if we decided to do things differently on the wiki page

here are the lines from the wiki:


Leading Generators

This category lists presets that will block signal flow from the left to them. Usually they are placed at the beginning of a given chain or sub-chain. However, you can prevent them from blocking the signal flow from the left by bypassing them. For more in-depth explanation see the Wiki page about Signal Flow

Following Generators

This category lists presets that will NOT block the signal flowing from the left to them. Usually they follow Chain inputs and/or Leading Generators. Keep in mind though that some (if not all) of the “following generators” are perfectly capable of generating signals on their own (i.e. even if there is no input from the left!) due to e.g. feedback patching within the unit itself and some units capability of selfoscillation. For more in-depth explanation see the Wiki page about Signal Flow


i will also add the results of my brain storms here. they might illustrate what i was up to
(though some of them can be ruled out for rather obvious reasons :rofl: ):

Principal Generators
Chief generators, Leading Generators, Head Generators, Absolute Generators, Oneway communicators, oneway generators, right wing generators,

Processing Generators
Following Generators, Tracking Generators, Relative Generators, Sequential Generators, Consequential Generators, Succeeding Generators, left Wing processors, Appending Generators, (Annexing Generators,)

I’m just jumping in real quick here. I’ve had so little time lately that my musical ambitions have been reduced to reading the OD forum posts once in a while while procrastinating from business. Anyway, just to say I’m following the discussions but passively.

Like @iiii I find myself missing a more generic and immediate naming on that Wiki page for the categories. It might be less imaginative, but I favor mentioned Signal generator and Signal processor, and voice/effect/utility/etc. just because it feels more intuitive to me, when browsing the wiki, and I think newcomers will also appreciate the fact they don’t have to learn the “lingo”? Explanations are not problematic @mopoco and it’s well described, but I think the generic option would be more straightforward for most users.

2 Likes

Also I remembered this

This is not implemented yet, but it might be worth considering when thinking of naming conventions.

2 Likes

oh crap, I forgot about this, it’s going to be really hard changing my brain to use different words as I must have used these terms thousands of times, it’s deeply ingrained! I apologise in advance for getting it wrong hundred of times in the future :crazy_face:

2 Likes

thank you so much for your feedback!
i appreciate it.

is it ok with you if i supplied you with two backups and you’d go ahead and relate the moved and
added presets/units the way it can fit your intuitions?

please, keep in mind the change @odevices had introduced!

what i’d like to offer is that i reinstate the former structure and add the changes that Brian made.
from the second backup you could then extract the added presets/units and insert them whereever you feel right. what do you think?

thanks @Bparticle for the feedback on the description!
also thanks to everybody who opted for the familiar way of things!
i also believe that there is not much to argue about the force of habit :face_with_monocle:

though there is one assumption that i feel is not quite right:

following the forum i observed several times that especially for beginners it was
everything but intuitive that some units block the signal flow and some do not.
in a welcoming manner we had to refer the rookies to the wiki page on signal flow several times…
naming for the difference was debated, too.

what i’m basically trying to say here is, that not only the rookies, but we all will have to learn the upcoming ‘lingo’ that gives proper names for leading and following units as @Bparticle pointed
out.

this is the basic difference i had in mind and i don’t really care about the names. i felt that that information is quite important and an easy way to set two kinds of creatures apart in a way that would also make the patching ‘language’ of the er-301 more transparent. maybe it is enough to point out that info in the description of presets/units (i surely will) or we introduce a field for it like @iiii had attempted (and how we dealt with the sample question) or we just keep welcoming the newcomers via RTFM (aka you should really make yourself familiar with what Brian had said to the ER-301/Signal Flow - O|D Wiki. )

i miss this one, too. although not the one in a broader sense, but the type of “Full Voice” that
has v/oct and trigger/gate in the UI (so that e.g. 808 noise wouldn’t qualify as such). i was working on an additional field for the entries, so we
could characterize some presets/units and their resulting voltages more specifically. Full Voice/bipolar/unipolar/contionuous/quantized/random/cyclic/acyclic etc… like we did with the question of how to
inform the user about sample-based/sample-less

at the end of the day, i believe we all agree on what @iiii pointed out:

let me know whether it is already time to throw in the towel on my own experiment :cry:

OK, I took another stab at it just now:

http://wiki.orthogonaldevices.com/index.php/ER-301/User_Contributed_Presets#Sandbox_-_Tables

I feel like given the space constraints of a table the best way to do it is to use a “less is more” approach. So, given that I removed all of the attributes I thought were redundant with the following logic:

Discussion: Obviously we need a link to the discussion, but I realized the slickest way to do was to make the name of the unit be the link to the discussion. :bulb:

Firmware: I figure we’re going to keep the 0.3.x and 0.4.x and eventually 0.5.x, etc sections in general, so do we really need to list the specific firmware version? My rough understanding from the forum is that any unit made in 0.4.earlierversion will always work with 0.4.current, correct? Or if it doesn’t, I think we can safely assume that if someone is confused they can reference the discussion to find answers.

Use Samples: I know, I know, this was my whole thing, but in the name of minimalism I’m happy to abandon it.

Date: This was only useful to the miners, it doesn’t need to be there.

Data: I also took out any extraneous info from the attributes data itself too, like post numbers, etc, just in the name of keeping it clean.

And obviously I’ve added the controversial “Category” attribute. To be clear, I just put it there because I know we’ll want something. Whether it’s called Category or something else, or if the attribute uses terms like “Voice, Leader, etc”, I’m not committing anything yet, I’m just using those as placeholders until we sort out what we want to do.

So, overall, I think that looks pretty slick. Maybe less informative than the other format we have, but less of an eyesore I feel. What are other peoples impressions of the table format versus the individual entry format?

As for the rest of the discussion, I’ll get to that in another post…

1 Like

awesome! you did it @iiii

+1

absolutely (not)

you know, sometimes minimalism doesn’t seem to be the right choice :innocent: :wink:

-1

i am not so sure about this one. it would also roughly tell the user when the preset/unit was created.
it helps maintenance, too.
we could also turn it into the creation date of the creature (rather than the date of the edit of the entry)
nevertheless, i would also argue that it is not as important as other fields, say e.g. "sample"…:slightly_smiling_face:

+1, in fact it looks so slick to me that it certainly could deal with even more beef. i.e. with at least the sample attribute (maybe even Brian’s upcoming naming for effects/source containers?)

overall i think that table experiment is worth following and exploring a bit more.

i was thinking: couldn’t we have both? e.g. a comprehensive table at the top (the wiki’s table of contents doesn’t look that sexy to me anymore btw…) with links to the full entries and the full entries below. i’d really miss the screenshots and the demos and the individual download links in @starthief’s collection and the individual descriptions…

@iiii had also improved maintenance! now the code looks almost like the wiki template we are using.

big step forward in engineering = big step forward for the miner’s hard work. :+1:

@iiii: would it be possible that one template could be used for feeding both, the table as well as the full entries?

as for the CPU load:

  1. we will have to introduce two digit numbers (e.g. 04%), or the sort button won’t work properly…

  2. often times I didn’t substract the 3% idle cpu load of empty patches. ( I did though with @anon83620728’s pan mixer, which has a remarkably low cpu load!)Obviously for large CPU loads the difference of 3% isn’t that crucial. But when your patch is already at, say 50% you’ll think twice and get somewhat picky on cpu loads… e.g. you would then add less pan mixers from @anon83620728’s-master if they were adding 3% each. Which they don’t! Maybe we could specify this on the template page, so that we get used to substract 3% from the read out?

this is Brian’s description on the template page so far:
CPU (48kHz, normal latency) Make sure you don’t have any other creatures running on the ER-301, then got to admin/CPU Load. Leave blank if unknown/untested.

I knew you were going to say that :rofl:

I don’t think so. Not with my skill set anyway. I would imagine it to be possible if you used a javascript Mediawiki plugin that replaced the default table of contents with the table we’ve come up with. So, short of that, we’d have to put in two chunks of template code: one for the table and one for the full entry.

If we had both, in the table I would change it so the preset name instead jumped down the page to where the full entry was instead of going to the discussion on the forum, as the discussion link would be listed in the entry. Same with the date: if there’s both, leave the date in the preset entry.

It’s easy to turn off, I’ll do that once we figure out whether we want to have table only or table + entries.

I will admit there is a side of me that likes the minimalism of tables only. I get the benefit of screencaps and all that, but visually it looks like a mess in my opinion (maybe we need to institute a fixed table width for the entries, that would clean them up, hmmmm).

My own personal design philosophy is to assume the reader/user has intelligence and are keen to explore and figure things out of themselves. All of the “additional/extraneous” attributes we list ultimately can be discerned from the discussions on the forums themselves. It could be argued that a table only approach encourages readers/users to go an explore the forum’s in more depth rather that stalkerly grab presets and never engage.

But I also get the benefit of having both, for sure. I could go either way.

I will concede that this is a useful sortable attribute, but I’m clearly biased. :relaxed: I’ll add it back in in a moment.

I was thinking in the specific case of @Starthief’s collection that we would add each individual preset as it’s own row in the table, that way they would be sortable via the category attribute. There is quite a range of functionality amongst those presets. I’ll add that to my mockup shortly too so you can see it.

I have a suspicion about how that specific scenario is going to play itself out. If I was a gambling man, my guess would be that @odevices’s solution in how to express that would be to create additional file suffix’s. For example, I was thinking .unit would be replaced with .effect .source .1band .2band, etc. But that’s only a guess, we shall see and adjust accordingly.

1 Like

I’m quite liking the table. I think there’s enough info there to decide if the unit is something I’m interested in exploring right now, and I think it’s totally fair to send me to the forum to get more details. After all, someone probably spent a good chunk of voluntary time building the preset. Least I could do is go read what they have to say about it. :wink:

One idea that hit me for categorization was to borrow the Function search dropdown choices from modulargrid and try to fit each to one of those. The benefit would be that most people would, I think, be fairly familiar with these categories.

I’ll slowly back away again now with hands in the air.

Attenuator
Blind Panel
Clock Generator
Clock Modulator
Comparator
Controller
CV Modulation
Delay
Digital
Distortion
Drum
Dual/Stereo
Dynamics
Effect
Envelope Follower
Envelope Generator
Equalizer
Expander
Expression
External
Filter
Frequency Divider
Function Generator
LFO
Logic
Low Pass Gate
MIDI
Mixer
Multiple
Noise
Oscillator
Panning
Phase Shifter
Pitch Shifter
Polarizer
Power
PreAmp
Quad
Quantizer
Random
Reverb
Ring Modulator
Sample and Hold
Sampling
Sequencer
Slew Limiter
Switch
Synth Voice
Tube
Tuner
Utility
VCA
Video
Waveshaper

Edit: I could also volunteer to create a unit preset that fits the blank panel category so that you have one to put there. :rofl:

3 Likes

Indeed, anything up to hundreds of hours in some cases :slight_smile:

2 Likes

I like the idea of the categories coming from an external source that can be referenced or used as a guide, but the length of that list seems excessive. I’m going to go out on a limb and suggest there will never be as many ER-301 presets as there are eurorack modules :rofl: so as to necessitate that degree of classification. Also, when was the last time you saw a module on MG that only had one category assigned to it, which is unfortunately a requirement with a sortable Mediawiki table.

If I went throught the MG list, I would simplfy it as such:

Utility:
Attenuator
Clock Generator
Clock Modulator
Comparator
Controller
CV Modulation
Expression
Frequency Divider
Function Generator
LFO
Logic
Low Pass Gate
MIDI
Mixer
Multiple
Noise
Panning
Phase Shifter
Pitch Shifter
Polarizer
Quantizer
Random
Sample and Hold
Sequencer
Slew Limiter
Switch
Tuner
Utility
VCA
Waveshaper

Effect:
Delay
Distortion
Dual/Stereo
Dynamics
Effect
Envelope Follower
Envelope Generator
Equalizer
Expander
Filter
Reverb
Ring Modulator

Voice:
Drum
Sampling
Synth Voice
Oscillator

Not Relevant to 301:
Blind Panel
Digital
External
Power
PreAmp
Quad
Tube
Video

What kind of CPU % do you think it’ll use? :rofl:

#truth #respect

i agree, and your points made me lean more and more towards the table-only-solution the last couple of days.
still, i had a bad feeling about abandoning the longer entries all together. and when i tried to insert some presets in a chain just to play around with them it occured to me why. on the er 301 sd card i have a single folder where i gather those presets. obviously that folder only contains the names of the presets and that list got big pretty quick. (there are already around 30 presets if i’m not mistaken.) so its getting harder and harder to tell the actual function (let alone remembering the usage) of a specific preset from their names. some of them are more obvious some are not. i kept inserting presets and deleting them until i had found something that i liked. but wait a minute! stuuupid me, i got that cheat sheet for the clouds parasites v2.0 in front of me and i caught myself abusing our wiki list as a cheat-sheet while i only had to move to the forum for rather specific questions that were not answered by the entries .

long story short question: what do you think how important that use-case is and should be for further efforts?

i’ve got more reactions and questions to your ideas, will be back later…

maybe one thing: i just can’t imagine to live without the table anymore :slightly_smiling_face:
and in case we keep both table and entries it could also solve the problem of the categorization of the entries for we could just list them alphabetically. and whoever wishes to choose via some categorization the table can deliver more than just one respect/level.

Basically, what we’re saying is we want the description in the table somehow. :sweat_smile: I’ll take another stab at it.

I got closer, but it all falls apart when you hit sort.

I think the solution might be to make a table inside a table in the template page, but I’m crashing, I’ll get back in there tomorrow.

Snuck in a quick tweak before my squash match this morning :joy: and it’s got potential. Can’t figure out why the extra cells show up when you sort though, the table inside a table must freaking it out a bit:

http://wiki.orthogonaldevices.com/index.php/ER-301/User_Contributed_Presets#Sandbox_-_Tables

looks interesting! i don’t even mind the extra cells after sorting the table. kinda looks nice. also,
i will ‘misinterpret’ it as an indicator that the table doens’t show the initial order :face_with_monocle:

@Joe: please, could you confirm?
though i was actually making a point for the both-world-option, i also liked @iiii’s implementation
of the descriptions in the earlier states. only that i had some worries back then: the table only contained a few rows and with each refresh of the page that table first built up with the descriptions expanded and then collapsed to the desired state. first i took it as an interesting behaviour but then got worried that this (mis?)behaviour might lead to serious performance issues if we filled up the table with all our entries…
so, great tweak! again!

I think it looks great, if that’s what you’re asking me. :slight_smile: There are probably several things that could work well, and the current description-in-table format is one of them I think.