Wouldn’t you say that this could be fixed on the device with something like pre-assignments?
Sure but Dwarf is limited on footswitch number. In some scenario would be useful to have a tablet right below the mic on the stand and use it as “handswitch”.
4 Likes
Gotcha 
i’d really like that idea of a List you can just scroll through. I’m shure the MOD Team has these tools internally for keeping track. That thread here started 5 years ago and its hard to skim over.
I know those things take time away from other stuff but maybe that is something the community can handel - with oversight from the develeopers from time to time.
Do you mean a list of feature requests that you could scroll through?
If yes…
This is the only option that I would see as doable.
When a feature is requested, a lot needs to go on including most of the time shaping that in order to make as much sense as possible and to really bring any benefit. This is even a lively process that sometimes has a lot of iterations. Publishing it would make really little sense and a lot of work to maintain.
Aside from a minor convenience for a small number of users who are interested, what purpose would the list serve? I think the messier, less efficient way of having people show up to make their case for a feature or change is more democratic. I’ve seen a number of posts recently asking for things I’ve posted about over the years. It validates that others have the same ideas or frustrations and it’s a little more personal than marking a “Like” button.
For software developers, there can be unintended consequences to piling things into tidy lists. People have submitted a lot of good ideas: menu changes, operational overrides, full MIDI I/O, plugin components or bundles, reverb tails, pedalboard building, global settings, I/O profiles, crossover and mixing options, more capabilities for looping and live recording, audio interface support, mobile interfaces, display modes for live performing,… The pragmatic developer will look at that list and cry because they know they can only accomplish a small portion of it and the untouched items will leave customers disappointed.
One way other groups have handled this is by publishing roadmaps, which can be as simple as a list of a few items grouped into a few arbitrary dates. A document like this shouldn’t take much than a few minutes per major release to edit and I expect that software teams on big projects usually have a keen sense of what is waiting in the wings to be developed. It’s a relatively easy way to signal intentions for the next few to several months of development and people tend to engage a little more when they’re excited that a desired feature might be delivered. However, with humans involved, even a roadmap can end up generating additional support in responding to hurt feelings, apparently broken promises, and other non-helpful responses that people choose to engage in.
8 Likes
You are right. A Roadmap is the common way to publish features. This list is just a matter of convenience (for me) until there is such a thing. Maybe it’s just the dwarf thread that is so cramped or there is no problem at all and i just have to read the whole thread. ^^
1 Like
Trust me, if we were publishing it as a list, you would have even more than here to scroll. We save all the requests, some make it through the development roadmap, some are somehow shaped, some others are dropped and even others stay waiting for better days to get them implemented
1 Like
A roadmap would have the advantage that you can read everything ~simply/clearly “at a glance” what wishes/features were proposed by the users and whether they were perceived by the mod team as well as how likely they are to be implemented or have a low priority or are impossible to implement, … .
A roadmap must not be obligatory/binding for the mod team but rather that we users see what has already been proposed.
A thread (or several threads) that has several posts is very tedious to sift through and capture all ideas / wishes. This has the consequence that some things are posted twice and you (Mod Team) often responds to the same ideas or … .
IMHO
4 Likes
I understand the request - and I’m mapping it by the way. My only personal feeling biased by looking inside, is that such things will just bureaucratise a process and give more work to an already overwhelmed (and short) development team.
1 Like
Allow system settings editing via WEB UI.
5 Likes
Add a separate 6 bands EQ for phones output. I’m not sure if it is already possible to differentiate main output EQ and phones EQ.
2 Likes
Do you mean the headphone out? As far as I know, this branches off the main outputs so it can’t be treated separately, unfortunately, it can only be attenuated. @Jan would be able to tell you in a more accurate way
1 Like
Yep, I mean headphones. I’d like to have a schema like this:
The split to the headphones is in hardware so seperate eq would not be possible without changing the hardware. Perhaps something more like this image although like I said, Jan knows much better than me so I will preface this by saying this may not be completely accurate 
3 Likes
3 Likes
This is impossible to do sadly.
The device does not have a clock, it does not know what time it is. Even if you were to connect the PC to it in order to give it the time, it will forget on the next reboot (which can be straight away, next week, next month, next year etc)
2 Likes
Gosh! You killed me Maybe a smart sorting algorithm on filename? Windows Explorer does it
somehow.
were those recordings made with screcord plugin? then I think we just need to ask @brummer to name files with leading zeros for easy sorting.
3 levels should be enough I guess, gets you 999 recordings before sorting is a problem.
1 Like
It would work as a workaround but obviously it would be better to have it system-wide.