First steps with the Magus, so many questions

mars · March 9, 2019, 11:23pm

Hi trotz, thanks for supporting our Kickstarter and welcome to the forum!

First up apologies for the lack of documentation, and good demo patches, I understand how frustrating this is.

You should have received a two-page Getting Started document, if not please find it here.

Like the OWL (Kickstarted in 2013!), the Magus is very much an ongoing project, and we will be adding features (and documentation) over the next weeks and months, if not years. It’s not just a product but also an open source ecosystem, with a substantial community of users and lots of exciting plans for the future.

Our priorities so far have been, roughly:

working hardware
working firmware
patch library support
user documentation
sample patches

Having experienced delays already we wanted to ship as soon as we could tick off items one and two. We hope you understand.

Now to your questions:

We’ll make another Magus firmware release in the next week or two, and we will also simplify the firmware upgrade procedure. I’d recommend you hold on for this as it will make the whole thing much easier.
There’s a stereo pair of ins and outs (adc and dac) and you use e.g. r Channel-A to read the first parameter, r Channel-B to read the second. Check out the tutorials @antisvin linked. A Magus patch is exactly like an OWL patch, but with more parameters. For now, in Pd, you can only use parameters A to H, but this will change shortly (with FAUST, C++ and Max gen you can use all of them).
You can draw on the screen directly in a C++ patch, but in Pd you are currently more limited, but you can print messages and they will appear on the screen.
We don’t have any Magus-specific Puredata patches yet, we need to do some work on our online server and patch library webapp first. But there are lots of OWL Pd patches in the patch library [1]
The two example patches are coded in C++ and are on github [2]
Create an OWL patch in the patch library, click Compile, then click Load (or Store to save permanently)
The MIDI mini-jack and adaptor will provide an extra MIDI interface, this is not supported yet in the firmware.
EXT is for an I2C protocol, also to be completed in a future firmware release.
In and out: oh yes, we need to cover this in the Getting Started document! Sorry!They are stereo line-level inputs and outputs. They can be used instead of, or along with, the Eurorack-level mono ins and outs at the top left and top right corners of the main module respectively.
USB ports in Puredata: you can use ctlin, ctlout, notein, noteout et c as normal.
Yes here is absolutely the right place to ask questions!

→ all great questions, thank you for posting them. Hope my answers help, don’t hesitate to ask for more information. I’ll go create a Magus category now

[1] Patch library: OWL Patch Library – Rebel Technology

[2] Magus KickBox and LorenzFM patches

github.com

marsus/MyPatches/blob/master/KickBoxPatch.hpp

#ifndef __KickBoxPatch_hpp__
#define __KickBoxPatch_hpp__

#include "MonochromeScreenPatch.h"
#include "VoltsPerOctave.h"
#include "Cymbal.hpp"
#include "BassDrum.hpp"
#include "Sequence.h"
#include "SynthVoice.hpp"
#include "MonochromeAudioDisplay.hpp"

class KickBoxPatch : public MonochromeScreenPatch {
private:
  SynthVoice* voice;
  CymbalVoice* hat;
  BassDrumVoice* kick;
  Sequence<uint32_t> seq[5];
  uint8_t midinote;
public:
  KickBoxPatch(){

This file has been truncated. show original

github.com

marsus/MyPatches/blob/master/LorenzFMPatch.hpp

#ifndef __LorenzFMPatch_hpp__
#define __LorenzFMPatch_hpp__

#include "MonochromeScreenPatch.h"
#include "CircularBuffer.hpp"
#include "SineOscillator.h"
#include "BiquadFilter.h"
#include "Sequence.h"
#include "Envelope.h"

/*
 * The Lorenz attractor is a set of chaotic solutions of the Lorenz system.
 * http://en.wikipedia.org/wiki/Lorenz_system
 */
class LorenzFMPatch : public MonochromeScreenPatch {
public:
  float x, y, z;
  float dt;
  const float a = 10.0;
  const float b = 8.0/3.0;

This file has been truncated. show original

trotz · March 31, 2019, 6:18pm

Hi mars,

Thanks for your help.

I’ll wait for the firmware update and meanwhile try to make sense of the available pd patches to see how they translate to the Magus. I guess that as soon as I can take a look on one of those specific magus pd patches I’ll be able to learn some useful stuff.

Meanwhile I’ll use what’s available and keep posting specific questions if I get stuck.

Regards!

pfawcett · September 26, 2019, 3:06am

Howdy. I’ve had my Magus for a while. I don’t have any issues, but I do have some questions.

Many Owl Patches have a control for the push button / switch and it’s part of the default dev patch… but I can’t find any way to trigger the ‘switch’ on the Magus as it has no switch. How is the switch mapped on the Magus? Or do those patches just not work on it (as many seem to be like pedal patches that only work when engaged).

You mention about, that new firmware is on the way shortly that will make updates easier. I looked at the github page and the last release seems to be 20.5, released on March 5th, which seems to predate your comment… Is that new firmware on the way?

If I wanted to install it, how would I do that? I can not find instructions on this site, the git hub page, or the quick start guide. Are the instructions posted some where. I’m assuming it’s the same as for the Owl, but I actually couldn’t find the instructions for that either.

I think that’s it. At least till I actually try to write some of my own patches.

Thanks much.

waxdoctor · September 26, 2019, 2:00pm

Thank you for trying to help here!

mars · October 1, 2019, 9:29pm

@pfawcett : Yes lots of the pedal-effect patches use the pushbutton, which the Magus obviously doesn’t have. And then the Wizard has four assignable buttons, making it even harder to use the same patch across products. The idea is that since copying and modifying patches is relatively easy, you could make a version that is adapted for your device.
But I guess we could implement a type of compatibility mode, so that buttons get mapped to unused parameters on the Magus. That might be useful.

New firmware: there’s always more on the way! Admittedly sometimes a long and windy one. Superuser @ykmm has just recently been working on a great contribution which will improve Pure data patches for Magus. It fixes a key usability problem: At the moment, when you make an OWL Pd patch, the parameters are all called things like ‘Channel-A’ and ‘Channel-B’. So if parameters are mapped to controls with their designators, then how do you give sensible, readable names to your controls that you can see on the Magus screen? . ykmm’s pull request allows you to set a custom OWL name with an attribute in the patch, which is very neat.

When we have a new Magus firmware release ready we will also publish instructions on how to upgrade. It’s all done with MIDI Sysex message under the hood, but we’d like to make a website update to make it real easy to do from the browser.

pfawcett · October 11, 2019, 3:09am

Thanks much for the reply. Makes sense about customizing. I’ve been too busy lately with my day job to do any side coding, but I have forked the max patch repo and hope to be able to tinker shortly.

Good to hear that firmware updates will come as they come. I fully understand how development can be an unpredictable process. I do testing and development for a day job, so delays and unforeseen issues are well known.

Ive noticed that some patches have the A/B… names and others have readable names. It would be awesome to have that support for PD.

Sysex makes sense and is reasonably easy to use, so that’s cool.

Thanks again.

mcc · October 18, 2019, 8:13pm

Hi, got my Magus up and running, super excited, gonna try to make a patch today!

A couple minor questions:

I got the desktop version, and it seems to not quite sit flat on a flat surface, it rocks back and forth a bit diagonally. Is this normal, is there anything I can do about it?
The behavior of the encoders is a little odd. It seems like I consistently need to “tick” the encoder twice to get one value change in a parameter, and the first time it ticks it usually seems to tick “backward”. IE I pick an encoder, I begin turning, it “ticks” twice and the parameter moves one value opposite from the direction i’m turning, I “tick” twice more and it returns to its starting value, then I “tick” twice more and now the value has moved one value in the direction I am turning. Is this surprising?
What exactly does the “Ext” output on the back do?

mars · October 18, 2019, 8:12pm

Not flat: nope, I’ve not seen that! Does the bottom panel look well aligned, or is it possible the whole case might have been skewed somehow?
Encoders: yes I’ve noticed this recently, and I’m sure they didn’t used to do that. I think it must be a problem introduced with a change in the latest firmware code or libraries, maybe related to parameter smoothing. I’ll do some digging on the weekend.
‘ext’ out:it is connected as a MIDI output but that is not enabled in the firmware yet. I’ll bump it up the todo-list.

mcc · October 18, 2019, 8:41pm

@mars:
The bottom panel looks fine, the rocking is as if the topright and bottomleft feet are a little shorter than the topleft and bottomright feet somehow. It’s pretty minor, it goes away if I set the Magus on top of a mousepad or a piece of cloth or something.

If the encoder wobble/“going backward” could be fixed in a software patch that would be great! Note I haven’t attempted to upgrade the firmware or anything. Is there a way to tell which version of the firmware is currently installed? (EDIT: the webpage says when I connect I have v20.5, but i don’t know where to look if that’s the newest)

The EXT thing makes sense. That sounds like a cool feature but is of low priority to me personally since a lot of my MIDI devices are USB-MIDI anyway.

I have a couple questions/issues I encountered while making a patch today, maybe I will make a separate thread for those.

Thank you for the help!

ykmm · October 21, 2019, 2:02pm

Hi everyone,

as @mars said a few posts ago, I am helping to add some functionalities in puredata patches.

I am interested in both the musical and technological aspects of electronic music, the magus is the perfect opportunity to learn both, and after getting a better grasp of the hvcc code generator and the OwlProgram patch builder I added some functionalities ad made the Pull Request.

The PR we are working on will allow the following:

use of all 20 channels on the magus
channels can be assigned a label which will be displayed on the magus
channels can be set to have a min, max or default value
channels can be set also to output using a [send] object (but not [send~] objects)

Setting those values is done by means of annotations, which are strings prefixed by an @ symbol and are written inside a puredata [r] or [s] object.

The following annotations are available:

@owl
@owl_min
@owl_max
@owl_default

@owl allows to set the label, and also min max and default values

[r Foo @owl A] will assign to channel A the label Foo

[r Bar @owl A 0.0 1.0 0.5] will assign to channel A the label Bar and set its minimum value to 0.0, maximum value to 1.0, and starting default value to 0.5, float values received by this input will be scaled appropriately to the range 0.0->1.0

[r Bar @owl A @owl_min 0.0 @owl_max 1.0 @owl_default 0.5] is equivalent to the above example.

The first syntax is concise but a little difficult to read, the second one takes more space but is more explicit.

[send] objects can be associated to channels on the device, allowing them to output float values, all annotations can also be used.

[s Baz @owl A] will use channel A as output and the label will be shown as Baz> on the Magus.

As mentioned above, [send~] obects are not supported, from the perspective of puredata this means that you can output from a channel only control data and not signals.

mars · October 22, 2019, 7:46pm

This is really awesome @ykmm, great work!

It’ll be useful not just for Magus users but also makes the patches much more readable. The min / max / default options are also really handy and saves on a lot of boiler plate multiply/add blocks.

To illustrate what a patch with annotations looks like, here is a (really silly) example:

If you are impatient to try it out you can use the dev.rebeltech.org server, but only @owl annotations are supported, and not yet for all parameters.

andrejkobal · August 29, 2020, 4:57pm

Hi wondering how far did you get it with this. Really interested in using the Magus out in Pure Data. Please also excuse my ignorance but I’m coming from the Max Gen environment which is a bit similar but any example would really help me get started. Unfortunately, the link bellow posted by @mars it is not reachable anymore. Any Help much appreciated. THX

ykmm · August 31, 2020, 1:11pm

Hi,

unfortunately I was not able to work on this any more, however I can see that @mars has integrated the proposed changes in the git repository, but I don’t know if they are already available on the web patch generator.

You could however use a virtual machine with linux, and by following the instructions here you could build the patches on your own. (Btw, there is an error in the guide, the line “git clone GitHub - enzienaudio/hvcc: The heavy hvcc compiler for Pure Data patches. OwlProgram/Tools/hvcc” should really be “git clone https://github.com/pingdynasty/hvcc.git OwlProgram/Tools/hvcc”.

As for the patches I need some time to find the ones I created as test, and see if they are in working state, (meanwhile try to look at my post on october/2019 which should show the correct syntax to use for send/receive elements).

andrejkobal · September 1, 2020, 9:49am

Thanks for the feedback. Yes any patch would be helpful. Thanks again.

mars · September 4, 2020, 2:34pm

Quite right, fixed!

I’ve deployed @ykmm’s changes to the live server so you can now use the much-improved parameter naming scheme, plus min/max/default settings for input parameters!

Here’s a simple example showing three different ways to assign an input parameter (Pure data receive) using the new @owl attribute.

[ r Osc1 @owl A ]

Creates a parameter called Osc1 and associates it with Parameter A, ie knob A. Values will be 0.0 to 1.0, with load-time default 0.5 (only relevant for Magus and MIDI-controlled parameters).

[ r Osc2 @owl B 0.25 0.75 0.5 ]

Creates an Osc2 parameter with range 0.25 to 0.75, and default value 0.5. Min, max and default are all optional: it is possible to specify only min and max, only min, or none at all.

[ r Osc3 @owl C @owl_min 400 @owl_max 4000 @owl_default 800 ]

Creates an Osc3 parameter with range 400 to 4000, default value 800, using explicit attributes.

Send (output) parameters are as easy, simply send a value between 0.0 and 1.0 to e.g.:

[s Send1 @owl F]

to send it to output parameter F.
Note that output value scaling using min and max values does not yet work, so values must be scaled before!

This new paradigm not only leads to more beautiful patches, but also sensible parameter names that can be displayed on devices that support it, ie Magus.

Patch is here:

mars · September 4, 2020, 2:42pm

antisvin · September 4, 2020, 3:36pm

Note that output value scaling using min and max values does not yet work, so values must be scaled before!

This probably requires an explanation that parameters have 12 bits of precision, which means that you can use values from 0 to 4095.

mars · September 4, 2020, 7:53pm

Actually in Pd (and gen~ and FAUST) the values are normalised to 0 to 1 floats, just like the input parameters.

antisvin · September 4, 2020, 8:21pm

Sorry, haven’t noticed that it was mentioned that they’re normalized after all. Or maybe HardFaults have become contagious.

mars · September 5, 2020, 6:52pm

When HardFaults reach R > 1 then we’re really in trouble!