Posts made by join

We'd like to one day (and this would be the right time to introduce user fingerings and such), but currently, with a software development team of one, we have too many more urgent priorities, so it's not in our short/mid-term plans.

Great stuff! Thanks!

I'm the programmer. Once the arpeggiator is done and the current bugs are ironed out, we'll release a v1.0.
But don't get too hung up on version numbers, they're just numbers and don't mean much. What matters more is that you're satisfied with your Anyma as it is.

@andyhornblower:

• I'd like to support SysEx-based loading/saving/renaming of patches some day, for the reasons you describe.
• We don't plan to end support of old operating systems for now. In fact, I'm fiercely opposed to that due to the waste it generates, and I hope we'll be able to continue supporting old systems (Windows 7+, OS X 10.9+) as long as we realistically can.
• Any detailed info about your crashes/restarts are very welcome (descriptions, videos, specific circumstances, any reproducible steps if possible; send to support@aodyo.com and say they're for join). Our personal Anymas don't crash, and they can run for days without freezing in any way. If yours do, this is something we need to fix. As opposed to some other "reliable" bugs, these ones tend to be nasty because they don't appear reliably, every time you do a particular thing, so it's very difficult to observe them and find where they come from. Some aren't even software bugs, but hardware defects, which makes the problem even less trivial. Hence, the more data we get, the better the chance to catch them.

@neilcmanson What you've encountered isn't a bug, it's an unfortunate UX decision of mine that backfired :).
We "dim" the labels of the parameters that aren't used/mapped in the patch (except the selected one, so that you get a chance to know what you're manipulating), but the way we dim them make them look garbled. We'll try to find some other way to visually discriminate unused parameters that doesn't involve scaring our users ;).

But don't worry, nothing is broken or corrupted, that's just a visual effect.

@boriss Could you describe how your Morph is setup (are you using an overlay that's supposed to send MIDI?), and could you please try again with the "Slow Charge" setting enabled on the Morph side? Thanks.

@boriss @MiloDodds I'd really appreciate it if you could send pictures of the Diagnostics screen (Settings > Diagnostics at the bottom of the menu) at the "USB HOST" section, ideally the entire section, and report if there is a "RCVD" line that increases when you use the controller. This will help me increase the Anyma's compatibility with USB devices. Thanks.

The patch-specific internal arpeggiator (the Arp parameter of the matrix that's currently unused) is the only feature missing before we can release a v1.0 firmware. We have no release date to offer, but it's in the high priority list.

Among the USB-MIDI keyboards that we've tested that don't work with the Anyma Phi, there are also the Arturia Beatstep, Beatstep Pro, and Microfreak, as well as the Novation ZeRO SL MKII. We also have controllers that "almost work", meaning that they are recognized and can do the basic stuff but they have problems, like the KMI QuNexus.

We're currently working on improving USB host compatibility with those controllers, and possibly others, so don't hesitate to report any non-working MIDI controller, either here or at support@aodyo.com.

This was indeed a bug, requiring you to make a change in the patch to allow it to be properly saved. Thanks for reporting.

This is fixed in the upcoming update, with the Export filename pre-fill too.

The info I've got: 225x120x70mm, 0.9 kg. This will be added in the manual for the next release.

This should be featured in a future update.

I created a "Patch Exchange" subsection and moved this thread to it. Feel free to create new threads as new awesome patches get created!

Thanks for the suggestion! Duly noted.

Please don't hesitate to report anything pertaining to your freezes or crashes to support@aodyo.com.

Please make sure you've updated your Anyma Phi to the latest version (you can find it here). There was a bug on the Windows version of the editor where the dialog boxes didn't appear, but it should be fixed with the last update.

At some point we would like to allow bidirectional edition of any patch parameter via NRPNs, maybe with a few accompanying SysEx messages for passing requests like getting parameter names, etc. No ETA, but that's something that we want to do, and when it's available someone will be able to make something like the M4L device you want.

Etant données l'ampleur de la tâche et la petitesse de notre équipe, nous n'avons pas prévu de faire une version française du manuel pour le moment. Mais ça ne doit empêcher personne de proposer des traductions…

This is described in the "Settings" chapter (p.48). You just need to go to the Settings (press the display encoder), and to "CC mapping". There you can modify the CCs for Expression and controls A/B/C/D.

The update is now available on the official Anyma Phi page.

This is something we could decide to do at some point, but we haven't planned it yet, because there are third party tools that do this well. If there is enough demand, we might consider it.

With macOS, there is MidiKeys, and for other platforms you can use something like VMPK. Just tell the program to output on the Anyma Phi port (to send the MIDI to your Anyma Phi, not the editor) and you should be good.

Thanks for the feedback, Christian, this is really appreciated.

We'll add some more details on all that in the upcoming version of the manual, but I can already answer the Artin part (as it will likely not make it to the manual, as you'll understand shortly).

The oscillators prefixed with "Artin" are based on the well-known family of macro-oscillators found in Mutable Instruments' Braids module, originally made by Emilie Gillet.
As per Emilie's guidelines on derivative works, we couldn't refer to Mutable Instruments or to the module names (Braids, etc.) in our distributed material, so we've prefixed all Braids-based oscillator algorithms with Artin, the name of a mathematician who discovered braid theory, so that people familiar with Braids can still have a way to look for familiar modules.

At the moment, forwarding the MIDI messages received from the DIN MIDI input to the DIN MIDI output is not possible.

However, on the USB-MIDI device connection (that's normally used to connect to your computer), sending MIDI data to the second output port "DIN" will result in this data being sent through the DIN MIDI output.

We're planning more flexible MIDI routing in a future update. Don't hesitate to share details about your needs, uses, or requests here.

Thanks for the info @Nelson_Baboon. With your info my hypothesis is that the specific issue relates to the fact that the input system of macOS issues a "right click" when doing a right click on a mouse, trackball, or a two-finger tap on the trackpad (when the trackpad is setup for doing so), but a ctrl + "left click", which should be functionally equivalent (since it was the only way to do it in the 80's when Mac mice only had a single button), are translated as "Ctrl + left click" and not "right click". The Cocoa toolkit (and some others) handles that difference just fine and shows a context menu either way, but a few GUI toolkits (especially when they're cross-platform and the macOS version is more of an afterthought) don't. Ours, in fact, offers you both choices, but I didn't know it until the issue was reported by you guys :).

You can morph between matrixes in the editor too! In the "GENERAL" section of the editor (first column), the two last modules are "MTX" and "MTXalt", respectively the normal and "alternative" version of the matrix you morph to when controlling the Morph control (which is located in the "MTX" module but not in "MTXalt").

As long as the amount of user requests doesn't exceed what a human can reasonably read or comprehend, it's better that we don't offer any voting feature, because to do the feature right it's important to have an idea of why someone wants it, what's their usage context, etc. The day we're overwhelmed with requests, we'll see :)…

As for patch storage, that'd be a nice idea, but it's a service we're unable to handle for now. However, I've just allowed Anyma Phi banks and patches on the forum, so if you'd like to share patches, just create a post and drop a patch, it should upload fine, just like the patch below. Once there are more than a few patches in the forum, we might create a specific category for them.

Thanks for submitting your experiences, ideas, feature requests, and patches!

tutorial.anymaphi-patch

Merci pour tes encouragements :) !

1. That nothing happens when clicking "Import patch" or "Import bank" on Windows is a problem, it's supposed to work. While we're fixing that, you can still drag and drop patches and banks from the Windows Explorer to the Editor window and it should still work.

2. The MIDI input and output you need to select in the Editor are those that correspond to the Anyma Phi. If you want to use your keyboard while still plugged into your computer, you would need to use a program such as MidiOx (or MidiPipe on macOS) that can forward a MIDI input to another MIDI output. Or you can simply plug your MIDI keyboard directly to your Anyma Phi. The Editor is a kind of remote control for the Anyma Phi, nothing more.

3. This looks like a Windows limitation, and if so, there's nothing we can do and it's indeed infortunate. Again, something like MidiOx could help because you could duplicate the MIDI data onto two different ports.

@nelson_baboon USB being backwards-compatible, it won't be a problem.

OK, we'll fix the editor so that Ctrl+LeftClick does the same as a RightClick on Mac.

@bibenu OK, so when you say "right-click", you are always doing a ctrl-tap/click, right?

If you plug a microphone or an instrument into the LINE IN port, its sound will replace that of the internal piezo behind the case, and will be used as well in the Piezo Pling patch. Can you get any sound with this method?

You will always find the release notes in their own chapter in the manual.
New versions will pop up on the Early Adopter page, but we'll certainly also announce them here or on a newsletter.

A few new patches are close to being released soon, and our sound designer is working hard on the next batch.

For modules and software features, we don't give timelines because we can't guarantee we'll finish them on time (our software development team of one can only do so much at a time). However, if there's vocal request for feature so-and-so, those'll tend to be the kind of features we'll prioritize in our to-do list.
So don't hesitate to suggest features and tell what's important to you!

Sorry for the annoyances!
I can just say the security questions on the forum are very necessary, unfortunately, because we're constantly hit pretty hard with spam and bots.
And for the power cable, you can also use a USB A extension cable.

We don't use anything special to make the context menu appear, so it shouldn't be problematic.
I certainly never had the issue (macOS Mojave, with Mac mini and MacBook Pro), but it could be something inherent to the GUI toolkit we're using.

Please give me any detail that could help with the diagnostic: OS and version, where do you right-click, whether right-click works better in other zones (e.g., on a virtual knob, on a module title bar, on a scope).

Also, if it happens on other apps, which ones?

Thanks!

Armando, I've sent you an email that should answer your request.

For issues like this, it's best that you send a mail to support@aodyo.com.

You will need to try again with updating until it succeeds.

On some operating systems, it's normal that the copy freezes for about a minute, but it completes eventually, and only then should you eject the ANYMAPHI disk. Ejecting the disk is also very important, as some operating systems wait until ejection to actually write the information on the disk.
Anyway, you can get information about what's really going on on the display of your Anyma Phi, which will show progress bars as well.

If you still don't manage to update, please try with another mini-USB cable, and with another computer or operating system, and please report back to us at support@aodyo.com what you tried and what worked and didn't, with details for your computer and operating system.

For issues like this don't hesitate to send us a mail at support@aodyo.com, we'll answer much more quickly.

The volume knob normally has a small "dead zone" at the beginning and at the end, but nothing that large.

This could be fixed by recalibrating the knob (in the settings), a possibility we're thinking of offering in a future update.

A way of sending/receiving a SysEx dump of the settings could be possible in the future…

@mickglossop Normally the editor app shouldn't have any problems running from Mac OS X 10.9 up to the latest version. Please send us a mail at support@aodyo.com with details on what you're experiencing with Catalina.

Typically, "Source 2" would allow you to make a secondary timbre appear, on top of the main sound you're playing. For instance, it could be a sub or bass (like in Resozen or Muta Flutes), or some harmonics or differently timbred sound that adds to the sound (like in Laraaji +)…

The name "Source 2" is deliberately generic because what's best as a secondary sound source is really different for each patch, as with "FX 1" and "FX 2".

Thanks for your feedback! On the MIDI front, what kind of info do you think is missing? We might add some additional (fixed) ways to edit the patch using NRPNs and other CCs (esp. for controlling the matrix) on a specific channel, so any clarification on how you'd use that is welcome.

@peter-ostry Yes, we will add the option to block the Sylphyo/Link from sending Program Change messages in a future update. We cannot commit on a time frame for this feature, but we'll get in touch as soon as a beta version with your feature is available.

Apologies in advance if I've misunderstood something or say something inaccurate, this is straight off the top of my head.

The angles the Sylphyo outputs come almost straight from its inertial measurement unit (IMU), with some postprocessing related to smoothing the response and correcting discontinuities where possible. That's probably why Ian gets the same kind of outputs with his own accelerometer.

Now, I guess the crux of the matter is the way we usually describe the orientation of the IMU, which is by giving three angles, one for each of the three axes (Euler angles), as if we applied successively a rotation around each axis from a given starting position.
It's a very useful way of describing a rotation, because it's very easy to map an angle to a particular physical movement, but it's unable to guarantee that the three angles stay independent at all times due to a problem called gimbal lock, which leads to some angles evolving in the same way despite applying a rotation to a single axis in particular situations, and other interdependencies like the one you've labelled "yaw" (which, by the way, would be really nice to exploit, even if it's really more of a side effect than an intentional feature!).
Depending on the order of the axes you choose, the lock happens in different conditions, and it's been a long time since we've done the movement system of the Sylphyo, but I think at the time I tried all the possible orders and went with the one that was the most conducive to being easily used in a Sylphyo performance.

By the way, due to this problem, the Sylphyo first offered only two angles (elevation and roll), and we later added the third (compass) due to popular demand, but as a "beta" feature, because the gimbal lock becomes really obvious when manipulating all three angles. Another reason for the "beta" status of the compass angle is that it's tied to our IMU's magnetometer, which has the bad habit of taking a long time to calibrate, and once done the compass angle might seem to "jump" in place. It's a common problem with IMU's, and it's also why your phone sometimes has trouble reporting your orientation correctly when you're using a GPS app.

Now, there's a way to escape the gimbal lock, which is representing rotations with quaternions, and fortunately our IMU is able to output quaternions. With this and a handful of formulas, it's possible to reconstruct a correct set of rotation angles, and it's clearly one of the next big things we would like to do in the movement area.
I tried doing so before we released Syphyo firmware version 1, but I was unsuccessful and we didn't have time for another try.
I will, at some point, but as people did get used to the angles as we have them, maybe we'll have to support both ways of representing things and let the users choose.
As for separating yaw and roll altogether, well that might need even more work :), but maybe switching to a quaternion representation first will help. Anyway, we'll see when we're at that point.

There's also a ton of other things we could derive from the IMU data, but this requires a good amount of research and development to get done right. In the past I've experimented with some movements like "elbow shakes" (using either hand to swing the bell to the left or to the right), but it didn't really prove very easy to perform :). Any good idea is up for discussion :).

@ijfritz, if you have any technical question you'd like answered, please contact me directly next time. Pedro did speak to me about this, but didn't really give any detail. As we're still deep into the Anyma Phi release, I don't often sweep through the customer support mail myself, and I don't visit the forum very often either, so I just saw your link to the video here. Pedro will call me at the end of the week to talk about your discovery.

Pouvez-vous nous en dire plus sur le comportement erratique de votre Sylphyo ? Notamment, quels sont les réglages de réactivité des touches avec lesquels le comportement est erratique, et est-ce qu'un changement de ces réglages résout le problème ? Merci.

The Link uses the same frequency band as WiFi, Bluetooth, and other consumer electronics devices. It might be that your WiFi router and your Sylphyo/Link are trying to compete for the same channel, in which case the loudest wins (certainly your router). To improve things, you might want to try to pair your Sylphyo and Link again, so that they will settle on another channel. Unfortunately, the Sylphyo and Link cannot "see" the busy channels in the frequency band, so they settle on a channel if they manage to communicate successfully during the pairing process. You might need to try a few times before finding a channel far enough from your WiFi router.

You might want to try the following beta version:

• for Windows: https://downloads.aodyo.com/sylphyo/beta/sylphyo-windows-1.4.8b10.exe
• for Mac: https://downloads.aodyo.com/sylphyo/beta/sylphyo-osx-1.4.8b10.zip

I added a "More sensitive" option in the Keys section of the settings menu. Once enabled, the octave keys should respond a bit differently, in such a way that it's pretty impossible to reproduce the issue observed in this thread with my Sylphyo.
You'll also find a parameter called "R.time octaves" that allows you to increase the reaction time when passing from an octave to another, which should help masking the undesired passing notes, for instance when switching from the high C to the low D of the next octave with the Sax fingering.

Let me know how it works for you.

It could arise if you use a light touch and move slowly on the octave keys, but it depends on the player and some Sylphyo are more forgiving than others. Generally it's recommended to push your thumb a bit more and move a bit faster, which effectively could require a bit of training. With the Sylphyo I have on hand, the issue (spurious note stuck) is apparent with an exaggeratedly slow thumb movement when I set the 5+2 mode, or better, a fingering where the thumb can change the note, like Recorder. Maxence can't reproduce the issue on his Sylphyo. @ijfritz If you don't mind, may I send you an email to discuss your issues in more detail and figure out something to mitigate it?

I LOVE this project, huge thanks to you Clint!

I like that the font could display "don't care", "half-hole" and "trill" alternatives. However, I share your concern about how easy it would be to sight-read the fingerings with the "don't care" symbols on it. Maybe something like a dot inside the circle would make it easier?

Also, I'm not an font expert, but I'm wondering whether it would be possible to offer any possible combination of fingerings, limited to open and closed states, which would amount to 512 different characters. This could help facilitate discussions over future fingerings and changes over existing ones by providing a way to quickly create fingering charts. This would also be beneficial for fingerings that offer many alternatives for a single note, such as the EWI.
In the same vein, would it be possible to compose a fingering using a succession of Unicode code points? I'm thinking about fonts like FF Chartwell that cleverly interpret characters so as to layout a drawing. Again, not a font expert, but I imagine it isn't that simple, and maybe limited to formats like OpenType?

Chiming in a bit late…

Breath control resolution is somewhat of a tricky subject. It's very easy to assume that a 7-bit MIDI signal isn't enough, but often I've found the problem lies in the perceptual mismatch between the breath signal produced by the performer and the perceived sound intensity of a sound produced by a synth.

Because we're very sensitive to that "jitter" between "no sound" and "a very faint sound", the synth should ideally increase volume/intensity veeeery gradually in the very low range (when the CC is 0, 1, 2, etc.), even if the curve can be steeper after that.

Having more extreme curves on the Sylphyo side would be a good idea (even regardless of this particular issue), but I don't think it would really help mask the perceived discontinuity in the very low range in most cases: if the sound is too loud at CC value 1 compared to CC value 0 (silence), then it's not good.
A 14-bit signal would help a little in this case, but I'm not sure it would be practical anyway because you would need a tremendous amount of accuracy to produce a smooth signal using the breath. And it could also bring in the timing issues Laurent talked about.

The synth will be smoothing your breath signal regardless of its resolution, and it'll do it at least over 32 bits, so it'll create the intermediate values your 7-bit or 14-bit signal lacks. The real question is how the synth smooths the signal: is it a good tradeoff between no perceived discontinuities and reactivity?

To me, the solution indeed lies in the volume curve, as Clint proposed. We're very sensitive to the difference between CC values 0 and 1, but I've yet to come across people complaining that there isn't enough steps between CC values 80 and 81. Bending the synth's volume/brightness curves to our perceptual expectations is more likely to bring about the desired results, in my opinion.

Have you found a good solution for this?
If not, you could try using some kind of program (like Max from Cycling 74) to produce the MIDI data needed to play the synth at a desired breath CC level, and check whether you hear a large discontinuity between 0 and 1.
If you do, then there should be some curve bending work to do on the synth side. If not, then we could try adding some new, more extreme curves on the Sylphyo side and see if it solves the issue.

I've also had my share of "what's that thing" and improvised 30-second demos for airport security officers :), but I never had any issue, be it with our without a case. As it contains a battery, you need to take it in cabin.
I also fly with some of our weirdest electronics prototypes without their enclosure and with wires everywhere, but it hasn't raised any concern so far.