As to your two conditions, I don’t agree with the first point at all: the app gets updates with new features then the manual/help info gets updated accordingly - it doesn’t need to be a never changing ‘finished’ product to have a manual. For example, @rs2000, the Flexi help text needs updating to include the Stretch capabilities - it’s not rocket science!
The second, fair enough i guess, but why not make it official so that it’s more available as i resource for app users? If @giku‘s official position is that support is provided by beta testers on the forum here, why not say that and have a link directly here from when you press Help in the app? Wouldn’t that make sense and be more helpful for beginner users?
@Robin It's not my official position and docs willl be updated very soon. I had to release this version earlier (ASAP) due to a crucial bug that appeared on ios18. Suplementary update is coming.
No problem, @rs2000, as I’ve said, all I wanted to do is help and I’m make Drambo as good as possible. Yes, i agree actually, if the module help descriptions were a bit more instructive, they would negate the need for an actual manual and be more readily available there and then when you need the information.
Cool, thanks for adding that context here @giku - without meaning any disrespect to them (they are absolutely trying to help fellow users), a lot of beta testers do seem to think it is a de facto official position from the comments made. Thanks again for the update and looking forward to the additional upcoming one. Cheers.
No doubt! And extremely helpful everyone here is too - I’ve been helped many times myself and am very grateful for it. It’s just not immediate help - you have to wait for a response which usually comes but might not - which is why, in my opinion, it can’t replace documentation of some sort; something which can be referred to and give you an answer immediately, as and when you need it.
I was going to give it a go with a wiki like site on GitHub (that I would transfer ownership of to the appropriate user) but if docs are already being worked on I’ll leave it. Don’t want to duplicate efforts!
No activity has started yet, and i appreciate a Wiki style documentation.
Not sure yet how to best structure it, we think that listing use cases with tags and example projects and presets would be a good idea but all suggestions are welcome.
As a recently-registered forum user who has asked a question or two but not much more, I can try to explain or justify why I find it difficult to use the forum as a means of accessing information that would traditionally be part of a user manual. The forum is good for questions like about solving a particular problem or learning how to an achieve a particular result, ie. "I want to emulate X particular vintage synth, how can I do it in Drambo?" But when it comes to wanting to understanding what all the knobs and settings and parameters do in general and how they interact, it's difficult to ask the question in a way that solicits a comprehensive answer. The main question I have every time a try to seriously dig into Drambo is, "what exactly does this knob/button/mode/etc. do?" And I have this question for many modules. For instance, in the Decimator module, what is the difference between each mode? In the Quantize module, what unit is the resolution measured in? These are not questions about use-cases -- those types of questions are can be easily answered by sharing demo project files. It's a question about understanding what exactly each adjustable control or parameter on each module actually does.
So @rs2000, I agree that having a guide to demonstrate use-cases is helpful, informative, and a step in the right direction. But I think putting together that kind of resource is a slightly different task than the one of documenting every input, output, and control on each module. The AE Modular wiki is an exemplary resource demonstrating what that latter task can look like.
"This manual is a community work in progress. If you would like to help out with completing this manual please send a PM to @admin at the AE Modular Forum. The status of each page can be seen on the Trello board at https://trello.com/b/HNd0dBt7/ae-manuals"
Note "community"
Now the only ones providing asistance to users, bug and crash fixing, solutions for users creations
across two Forums and a 1.9k strong Facebook group are Giku and the Beta Team and the Beta Team are doing it for free
because Giku needs to focus on making dRambo as stable as possible whilst creating new things for users to play with
so please be patient or can you encourage other users to assist in creating an online dRambo wiki or github.
The other thing you could do which I suggested to another forum member is to create a thread for each module
that needs more detailed documentation.
Giku has taken this thread into consideration and has updated the internal descriptions for the modules
on the beta so when the next update comes out there'll be more detailed descriptions so unti then...
Over on the Loopy Pro forum a forum member there has suggested creating a github so lets see.
Bear in mind AE Modular has a paid team.
dRambo is one developer with an entirely voluntary beta team who provide support in their free time.
My apologies if this sounds defensive however this is more along the lines of asking for patience and understanding.
I hear you @gravitas ! I'm trying to not be demanding of anyone else's time and energy. I'm greatly appreciative of the help that people like you provide for me and others on this forum :-) . I reckon that a wiki would be a more efficient way to organize the records and information that veteran drambo users provide here, instead of answering the same questions again and again as old posts get buried under new ones. You mentioned that there's another user who's creating threads for each module? I would love to see those threads and contribute, but I couldn't find them when I clicked back through the most recent pages of discussion topics.
I would happily contribute to the Wiki once somebody else launches it. The nice thing about having the AE wiki as a reference is that we can "steal" their page template and get away with only making some minor changes to tailor it to drambo - so less work for us as we stand on their shoulders.
@gravitas As ‘the other user’ referred to (I think), i hope nothing I’ve written here came of as ‘demanding’ anything? I simply pointed out that Drambo could do with a manual/proper help infrastructure to maximise its possible popularity - which, though some get defensive, it seems everyone agrees with ultimately.
This forum and its members are great at providing help, but when a user needs help understanding something, they want to be able to look it up somewhere immediately, they don’t want to post a question on a forum and then wait for an answer which usually comes eventually (on this forum at least) but may not. You need help when you need it, not when someone else happens to see your question and is kind enough to answer.
As for your suggestion to open up individual threads here concerning individual modules, I’m afraid i don’t have the time to do that and, when it comes to the more complicated modules and aspects - such as the Maths modules - i simply haven’t the expertise to write about them as i don’t know what they do really.
By the way, i assume you did see @giku‘s post saying that updated documentation is coming?
I’ve said repeatedly how much i loved using Drambo and how much i appreciated the help which is given on this forum so I hope I’m not being perceived as the bad guy here just for daring to suggest that Drambo isn’t absolutely perfect as it is?
The creation of a comprehensive manual is a critical component of the software development lifecycle. It is recognized as current best practice, essential to user experience and operational efficiency in modern software development.
If you really think about it, a thread per module is a terrible idea.
@aaa Descriptions about controls in modules should be covered by the module help in the first place, I think.
Some modules already contain help in this level of detail.
If certain modules lack that detailed help or are difficult to understand, please let me know which and I'll do my best to update the respective help texts.
By this style I meant the link I posted from the hel documentation of Obsidian. There’s free versions of “digital gardens” and I think that will be perfect.
The idea would be so that later on if people want to add quick Drambo recipes they can link back to any of the modules that will be documented to it. So we will have a graph of sorts be created that will grow and grow.
When considering the structure of this new documentation, in addition to recipes, please consider this from marketing 101:
The difference between features, benefits, and other elements like value propositions is often clarified through a framework that helps guide messaging.
Here’s how these are typically defined:
1. Features: These are the factual, specific attributes of a product or service—what it has or does. They’re usually objective and describe the “what” of the product.
• Example: A phone has a 12MP camera, 128GB of storage, and a 6.1-inch display.
2. Benefits: These are the outcomes or positive impacts that features provide for the user—what those features do for them. Benefits answer “why” a feature matters by highlighting its usefulness.
• Example: The 12MP camera allows you to take high-quality photos, making memories vivid and clear.
3. Value Proposition: This is a statement that communicates why a consumer should choose a product over a competitor’s. It combines the benefits with an emotional or practical outcome that resonates with the consumer.
• Example: “Capture life’s moments in stunning detail—always keep your memories in focus.”
4. Advantages: Sometimes added to clarify how a product compares to competitors. These focus on how it outperforms similar products.
• Example: Compared to other phones in its class, this camera performs better in low light.
5. Emotional Connection: This is less about functionality and more about connecting with the customer’s desires or identity. It goes beyond the logical benefits to inspire brand loyalty.
• Example: Owning this camera isn’t just about taking photos; it’s about cherishing every moment.
Focusing on benefits and value propositions rather than just features is generally the key to effective communication.
Funnily, I've just recently discovered Obsidian but so far I have zero experience using it in such a project.
@offbrands Is there an example help use case that could serve as a template? Specifically, in which sense would the graph help? Thanks!
@Nuuksio I'm all in for a structured, well-thought out approach in the first place. Your points are certainly worth considering when building a first "beta" template.
@aaa suggested the AE Modular Wiki as an example - I wonder if it made sense to pick the best of each different approach?
Comments
Accidental post on my part, apologies.
@rec Thanks for you further comments.
As to your two conditions, I don’t agree with the first point at all: the app gets updates with new features then the manual/help info gets updated accordingly - it doesn’t need to be a never changing ‘finished’ product to have a manual. For example, @rs2000, the Flexi help text needs updating to include the Stretch capabilities - it’s not rocket science!
The second, fair enough i guess, but why not make it official so that it’s more available as i resource for app users? If @giku‘s official position is that support is provided by beta testers on the forum here, why not say that and have a link directly here from when you press Help in the app? Wouldn’t that make sense and be more helpful for beginner users?
@Robin It's not my official position and docs willl be updated very soon. I had to release this version earlier (ASAP) due to a crucial bug that appeared on ios18. Suplementary update is coming.
No problem, @rs2000, as I’ve said, all I wanted to do is help and I’m make Drambo as good as possible. Yes, i agree actually, if the module help descriptions were a bit more instructive, they would negate the need for an actual manual and be more readily available there and then when you need the information.
Cool, thanks for adding that context here @giku - without meaning any disrespect to them (they are absolutely trying to help fellow users), a lot of beta testers do seem to think it is a de facto official position from the comments made. Thanks again for the update and looking forward to the additional upcoming one. Cheers.
On the other side I wouldn't handle this alone without such a great community
No doubt! And extremely helpful everyone here is too - I’ve been helped many times myself and am very grateful for it. It’s just not immediate help - you have to wait for a response which usually comes but might not - which is why, in my opinion, it can’t replace documentation of some sort; something which can be referred to and give you an answer immediately, as and when you need it.
Can’t argue with that one bit :)
in fact the main reason I passed on Loopy Pro when released was the missing documentation.
I hope I will prove to be wrong but it is my opinion :)
Hey 👋🏽 - are docs already being worked on?
I was going to give it a go with a wiki like site on GitHub (that I would transfer ownership of to the appropriate user) but if docs are already being worked on I’ll leave it. Don’t want to duplicate efforts!
@offbrands
By all means, yes please, go ahead!
No activity has started yet, and i appreciate a Wiki style documentation.
Not sure yet how to best structure it, we think that listing use cases with tags and example projects and presets would be a good idea but all suggestions are welcome.
Thanks a lot already!
+1
As a recently-registered forum user who has asked a question or two but not much more, I can try to explain or justify why I find it difficult to use the forum as a means of accessing information that would traditionally be part of a user manual. The forum is good for questions like about solving a particular problem or learning how to an achieve a particular result, ie. "I want to emulate X particular vintage synth, how can I do it in Drambo?" But when it comes to wanting to understanding what all the knobs and settings and parameters do in general and how they interact, it's difficult to ask the question in a way that solicits a comprehensive answer. The main question I have every time a try to seriously dig into Drambo is, "what exactly does this knob/button/mode/etc. do?" And I have this question for many modules. For instance, in the Decimator module, what is the difference between each mode? In the Quantize module, what unit is the resolution measured in? These are not questions about use-cases -- those types of questions are can be easily answered by sharing demo project files. It's a question about understanding what exactly each adjustable control or parameter on each module actually does.
So @rs2000, I agree that having a guide to demonstrate use-cases is helpful, informative, and a step in the right direction. But I think putting together that kind of resource is a slightly different task than the one of documenting every input, output, and control on each module. The AE Modular wiki is an exemplary resource demonstrating what that latter task can look like.
@aaa
Quote from the AE Modular wiki...
"This manual is a community work in progress. If you would like to help out with completing this manual please send a PM to @admin at the AE Modular Forum. The status of each page can be seen on the Trello board at https://trello.com/b/HNd0dBt7/ae-manuals"
Note "community"
Now the only ones providing asistance to users, bug and crash fixing, solutions for users creations
across two Forums and a 1.9k strong Facebook group are Giku and the Beta Team and the Beta Team are doing it for free
because Giku needs to focus on making dRambo as stable as possible whilst creating new things for users to play with
so please be patient or can you encourage other users to assist in creating an online dRambo wiki or github.
The other thing you could do which I suggested to another forum member is to create a thread for each module
that needs more detailed documentation.
Giku has taken this thread into consideration and has updated the internal descriptions for the modules
on the beta so when the next update comes out there'll be more detailed descriptions so unti then...
Over on the Loopy Pro forum a forum member there has suggested creating a github so lets see.
Bear in mind AE Modular has a paid team.
dRambo is one developer with an entirely voluntary beta team who provide support in their free time.
My apologies if this sounds defensive however this is more along the lines of asking for patience and understanding.
Thank you.
I hear you @gravitas ! I'm trying to not be demanding of anyone else's time and energy. I'm greatly appreciative of the help that people like you provide for me and others on this forum :-) . I reckon that a wiki would be a more efficient way to organize the records and information that veteran drambo users provide here, instead of answering the same questions again and again as old posts get buried under new ones. You mentioned that there's another user who's creating threads for each module? I would love to see those threads and contribute, but I couldn't find them when I clicked back through the most recent pages of discussion topics.
I would happily contribute to the Wiki once somebody else launches it. The nice thing about having the AE wiki as a reference is that we can "steal" their page template and get away with only making some minor changes to tailor it to drambo - so less work for us as we stand on their shoulders.
Thank you for your understanding.
We don't mind answering questions for new users because that's how we learn which is by asking.
"Demanding" is another thing entirely. ;) no, no, no not you.
I had made the suggestion to the user however I don't think they've decided to do so yet.
The dRambo search engine certainly needs improving, @wim over on the Loopy Pro forum had this to say
"Tip for getting more useful results out of the Beepstreet Forum search:
Don't use it.
Instead, go to google search, put in your search terms, then append site:forum.beepstreet.com. Thank me later. 👍🏼"
Many of the veteran dRambonauts have provided answers in an ad hoc manner
because we have conversations about designs and figuring out things
to challenge dRambo alongside being in the beta team etc see the aforementioned.
For instance I recently designed a preset that replicates most of the
priniciples of the T1-Torso sequencer because it was a challenge. :)
Resources like the AE Modular work for a reason, it's the way it's been organised so yes
we could use it as a template alongside the https://learningmodular.com/glossary/ .
I used the latter a lot when I first started learning dRambo because dRambo was
my first introduction to Eurorack and the documentation was sparse so
I did a lot of "translating" and buried myself in learning dRambo...anyway I digress...
@offbrands has started looking into Github so maybe the both of you could have a chat about it?
@gravitas As ‘the other user’ referred to (I think), i hope nothing I’ve written here came of as ‘demanding’ anything? I simply pointed out that Drambo could do with a manual/proper help infrastructure to maximise its possible popularity - which, though some get defensive, it seems everyone agrees with ultimately.
This forum and its members are great at providing help, but when a user needs help understanding something, they want to be able to look it up somewhere immediately, they don’t want to post a question on a forum and then wait for an answer which usually comes eventually (on this forum at least) but may not. You need help when you need it, not when someone else happens to see your question and is kind enough to answer.
As for your suggestion to open up individual threads here concerning individual modules, I’m afraid i don’t have the time to do that and, when it comes to the more complicated modules and aspects - such as the Maths modules - i simply haven’t the expertise to write about them as i don’t know what they do really.
By the way, i assume you did see @giku‘s post saying that updated documentation is coming?
I’ve said repeatedly how much i loved using Drambo and how much i appreciated the help which is given on this forum so I hope I’m not being perceived as the bad guy here just for daring to suggest that Drambo isn’t absolutely perfect as it is?
@Robin
Yes, you are the user I made the suggestion to.
No, I didn't say anything about you personally being demanding.
I mentioned in "an ad hoc manner".
That's a pity that you cannot start threads for the modules however two users are willing to try setting up a Github for dRambo.
You're going to have wait until that is setup for instant answers however
as mentioned we shall try to answer when we can and you can also look at
https://wiki.aemodular.com/pmwiki.php/AeManual/Modules and here
https://learningmodular.com/glossary/ for descriptions and uses for modules.
Though dRambo's modules seem generic (which was intentional), many of them do have real world equivalents.
Effects processors, oscillators and filters are obvious.
The Math modules can be hard to understand however that will certainly
be discussed with rookie dRambo users in the future in the meantime try experimenting
which is part of the nature of Eurorack and dRambo is designed specifically to be a modular playground.
If you had read my reply to @offbrands you would've read that I mentioned that
the internal documentation for dRambo has been updated in the Beta so should be there in the next update.
No one said you're the bad guy here.
@Robin in the nature of experimenting.
Here's another option, try using ChatGPT for module explanations.
It replies instantly.
The creation of a comprehensive manual is a critical component of the software development lifecycle. It is recognized as current best practice, essential to user experience and operational efficiency in modern software development.
If you really think about it, a thread per module is a terrible idea.
Agreed a comprehensive manual is critical however see earlier replies in regards to time and effort from Beta team etc.
It was merely a suggestion.
Individual threads could've encouraged other users in the community to interact however I can now see this is a terrible idea.
As mentioned earlier two users have kindly offered their time and effort
into creating a github so let's see if that gains interest from the community.
@aaa Descriptions about controls in modules should be covered by the module help in the first place, I think.
Some modules already contain help in this level of detail.
If certain modules lack that detailed help or are difficult to understand, please let me know which and I'll do my best to update the respective help texts.
The improved help is vey useful. Haven’t delved in detail but I can see in the more complex modules like flexi that is more detailed.
Thanks for your hard work (I was going to say @rs2000 but I don’t know who else has contributed, but @rs2000 surely did)
+1
Oh by the way.
I've just been asking ChatGPT and it's quite comprehensive.
I used this online.
https://chatgpt.com/
Here's a screenshot
Thank you!
Okay! I had some health things come up this week but I’ll be working on this throughout the next week.
I like the idea of having the definitions of eurorack along with Drambos version.
I’m going to work on it with a version of this style but like I mentioned on GitHub so it’ll be editable by the community
I’m not one to share progress as I’m a solution forward kinda guy.
But I will share my progress with @gravitas - this whole thing could take a couple weeks for a sold foundation but it’ll be worth it!
By this style I meant the link I posted from the hel documentation of Obsidian. There’s free versions of “digital gardens” and I think that will be perfect.
The idea would be so that later on if people want to add quick Drambo recipes they can link back to any of the modules that will be documented to it. So we will have a graph of sorts be created that will grow and grow.
hope that vibes with everyone!
When considering the structure of this new documentation, in addition to recipes, please consider this from marketing 101:
The difference between features, benefits, and other elements like value propositions is often clarified through a framework that helps guide messaging.
Here’s how these are typically defined:
1. Features: These are the factual, specific attributes of a product or service—what it has or does. They’re usually objective and describe the “what” of the product.
• Example: A phone has a 12MP camera, 128GB of storage, and a 6.1-inch display.
2. Benefits: These are the outcomes or positive impacts that features provide for the user—what those features do for them. Benefits answer “why” a feature matters by highlighting its usefulness.
• Example: The 12MP camera allows you to take high-quality photos, making memories vivid and clear.
3. Value Proposition: This is a statement that communicates why a consumer should choose a product over a competitor’s. It combines the benefits with an emotional or practical outcome that resonates with the consumer.
• Example: “Capture life’s moments in stunning detail—always keep your memories in focus.”
4. Advantages: Sometimes added to clarify how a product compares to competitors. These focus on how it outperforms similar products.
• Example: Compared to other phones in its class, this camera performs better in low light.
5. Emotional Connection: This is less about functionality and more about connecting with the customer’s desires or identity. It goes beyond the logical benefits to inspire brand loyalty.
• Example: Owning this camera isn’t just about taking photos; it’s about cherishing every moment.
Focusing on benefits and value propositions rather than just features is generally the key to effective communication.
Wow, I really like where this is going!
Funnily, I've just recently discovered Obsidian but so far I have zero experience using it in such a project.
@offbrands Is there an example help use case that could serve as a template? Specifically, in which sense would the graph help? Thanks!
@Nuuksio I'm all in for a structured, well-thought out approach in the first place. Your points are certainly worth considering when building a first "beta" template.
@aaa suggested the AE Modular Wiki as an example - I wonder if it made sense to pick the best of each different approach?
I’ve been using obsidian every day for around 2 years now. @rs2000 It’s a great knowledge management tool. I definitely recommend it.
I’d love to help contribute to this once it’s started and there is a system setup! I love obsidian wikis