Guidelines for Speakers and Presenters for LectureDemonstrations, Workshops, Talks and Presentations

Not only for Sonoj but for Videos, we offer these guidelines:

  • These are guidelines, not rules!
  • One time slot is 60 minutes in total including setting up your gear, testing it with the sound/video guys, questions and discussions and packing everything up again. Expect a pure presentation time is around 45 Minutes.
  • Presenting as a Duo is a powerful and relaxing concept we absolutely recommend! Share and divide the preparation time, or have one do the talking and the other one handling the computer. Or one can play music examples etc. This is especially reassuring if there is some small technical hiccup. You can continue your presentation while your companion quickly fixes the problem.
  • Furthermore: If you have friends or even a local group you can present your talk there first and improve and practice it together. This way your talk becomes the result of a longer group effort, which will surely increase the quality.
  • At the Sonoj Convention talks are done by people, not corporations. „Mr. Foo, Google“ will not be added to the schedule, only „Mr. Foo“. You can briefly mention your bio and work in the talk directly, if that has any benefit for the audience. Such a bio is mostly to establish authority in your field. A talk about guitar effects will not gain any credibility from „Creates AI blockchains for self driving cars at google“.
  • Assumptions you can make about the Sonoj audience. The “user”: Probably musically talented or meant to become so, subjected to advertisement of proprietary and commercial software and hardware, knows other musicians that might not be FOSS users, has a modest level of general purpose technical knowledge about computers and software, knows the basics about audio production and terminology: what is mono and stereo, what is MIDI, what does “track” mean, the role of EQs and compressors and so on
  • small scope: one usecase, or one program, one effect, one technique, one library, one instrument. Avoid overview talks. But comparisons in a narrow field are fine e.g. for giving context or comparing the subject of your talk to similar programs. See for example the talk „Drums“ in 2018.
  • Around a third (33%) of the time can be spent with pure music. Maybe open with a whole song 2 to 5 minutes before even saying “Hello, my Name is”, replay parts during the talk or use other pieces as comparison. That time does not include other audible demonstrations, like showing the features of a synthesizer or recording capabilities in a DAW.
  • The venue's projector has HDMI, DVI and VGA up to a resolution of 1920×1080 (native). Sound-Out can be done in a variety of formats and cable connectors.
  • User-centric and music-centric.
  • Practical advise: What did the audience learn during the talk. What can they use in their own music?
  • We encourage that people show pieces of music software that they use for themselves, and not developers showing their own software. If you are in fact a developer showing your own software maybe try to get into a “user mindset”.
  • Low Tech Factor. While the general level of technological knowledge, or the willingnes to learn, is higher in an open source context don't explain too much background info.
  • “No code”. Don't talk about programming code please, except the talk this exact subject, like Music Live Coding. Assume musicians in the audience, not programmers or software developers
  • We assume that everybody will be able to install and configure the software on their own. Please don't do an install guide. Please don't show how to “enable JACK as default output etc.
  • Start with music, then a preview and finally have a summary at the end.
  • Be aware what you want to achieve with your presentation. E.g. do you want to “WOW!” the audience and impress, inspire and motivate them? So they go home and work on what THEY want? Or do you want to teach them something so they go home and work on what YOU did. Both is good.
  • Finally, in case everything goes wrong :)