oinj

I wasn't even aware some places had prohibited pinball until I saw "Pinball: The Man Who Saved the Game". Great movie.

He never was a "spiritual leader". He was a med school professor. He had been ordained as a _upāsaka_, a lay Buddhist disciple, meaning he took the vow of following the five precepts and he was given this name by the people who ordained him, that's not a weird thing. He later was removed from the board of the meditation center he co-founded because he broke the precepts (adultery and lying about it to his wife, hardly a criminal)[1], so he was prohibited from teaching things. He died recently from cancer[2].

His approach in the book, which seems still taught at that center, probably because it's excellent, was to lay out a path for meditation practice that was inspired from classic Buddhist writings, but presented and explained with modern neuroscience.

Getting advice from a divorced guy doesn't look great, but thankfully there are many more role models to look up to, and (early) Buddhism requires very little faith and demands that you verify the teachings by yourself anyway.

[1] https://engagedharma.net/2019/08/19/culadasa-charged-with-se... [2] https://culadasa.com/

Great use case for animated transitions, check out this research project from 2010: https://www.aviz.fr/diffamation.

Here's an example of it in action with a Wikipedia article: http://tan.lille.inria.fr/diffamation/?lang=en&doc=saintdeny... (2015).

I've got this idea that third-party batteries are mostly crap and die very fast, but it's based on ≈10 year old experience (although the last official battery on my iPhone SE 2016 was the same)

Big fan of your OS X stuff! I still have a 11" 2012 MacBook Air with Core i7 and 8 GB RAM, if only I could use it as my everyday machine I'd be very happy!

I didn't know about Firefox Dynasty, it's very cool. (Wow, and Archive Plus and Preview Plus… you're killing it!)

What's your experience with those shady USB-C to Magsafe 2 cables/adapters? Old MacBook batteries are bound to deplete faster and faster every year, it'd be nice to be able to charge using what's most common nowadays.

Indeed: your comment made me curious, so I've read the article although I wasn't initially interested, and I gained a nice point of view about conversational interfaces to LLMs and how friction, usually a pure HCI concern, is being weaponized to bring about a profitable and inhumane world. I didn't need to read this today but will surely remember or think about at some point.

Thanks for wasting my time! You might just want to exert a little bit more effort next time to explain why you felt that way, which would make your hard-earned piece of advice a useful contribution to this place instead of that weird way of reminding everyone that you exist at the detriment of others.

SEEKING WORK | Remote | Audio, interactive and embedded systems

Location: Seville, ES and Dijon, FR

Remote: Yes

Willing to relocate: No

Main technologies: C++, embedded systems (STM32, PSoC, nRF), JUCE, Objective-C and Cocoa.

CV/Contact: https://www.linkedin.com/in/jonathan-aceituno-105694356

I've been designing and developing digital musical instruments and synths for more than 10 years, including two commercial products used by professional musicians around the world.

Combined with a background in HCI research, I offer strategic assistance, interaction design, and software development services to companies interested in building reliable interactive products, be they hardware or software.

I work using a positive, humane, and mindful approach aimed at understanding the underlying needs of stakeholders and making the best of a situation. I try to avoid dogmatism in my own thinking but at the same time respect existing rules and processes.

I'm currently working with a handful of small companies as well as a public research institution, and I'm looking to expand my network outside of France.

If you have needs that intersect my background and interests, or if you want to chat about making fun, profound, and expressive tools, or anything pertaining to HCI, software, DSP, or music, don't hesitate to contact me!

smoking_evidence4y@icloud.com

We had to switch to a more powerful architecture and chip but the voices are still dispatched on several processors. It'll be enough to withstand 16-note polyphony at 125% load, with some extra power left because we don't use the second core yet.

Thanks! The software doesn't connect to the network. You can use another computer or your mobile phone for activation.

I did a tiny bit of DSP and I've been exposed to the HCI/NIME community in the past, but that's it. Many modules in the Anyma are just reasonable implementations of clever formulae I didn't design but studied from papers :). And for the Mutable stuff, a lot of optimization work and tradeoffs to make. We are lucky to have a sound designer with a good ear. That said, we've been working for a while on our own waveguide models (Windsyo and others), and we have found some tricks I've never seen elsewhere. There's a lot to explore, especially when looking for "hybrid" acoustic-electronic sounds.

We also investigated iPlug2, but ultimately decided on JUCE partly because it was easier to find help.

The EaganMatrix (inside the Osmose) and the Hydrasynth are both great and each one has its own approach. I think the Anyma synths are less beefy, in terms of computational resources, but the synth engine offers more kinds of modules, more freedom in some way. Not that it's always useful to have 16 LFOs or envelopes, or to be able to modulate the curve of a mapping, but it sometimes makes trying an idea easier during sound design. As we started with a wind instrument (Sylphyo), we also take special care to make support for this kind of MIDI controllers effortless.

The synth engine in the Anyma Phi runs on a STM32F4. The UI and MIDI routing runs on a separate STM32F4. No RTOS, we find it much easier to reason with cooperative multitasking, and easier to debug. So far, we don't have any latency/jitter issue with this approach, although it required writing some things (e.g. graphics) in a specific way. The Omega runs on a mix of Cortex-A7 and STM32.

I have a pure software background but I came to appreciate the stability, predictability and simplicity of embedded development: you have a single runtime environment to master and you can use it fully, a Makefile is enough, and you have to be so careful with third-party code that you generally know how everything works from end to end. The really annoying downside is the total amount of hair lost chasing bugs where it's hard to know whether the hardware or the software is at fault. In contrast, programming a cross-platform GUI is sometimes hell, and a VST has to deal with much more different configurations than a hardware synth, you're never sure of the assumptions you can make. The first version of Anyma V crashed for many people but we never had the case on the dozen machines we tested it on.

Thanks. It's weird, we cross-compile using llvm-mingw from macOS and then run the Inno Setup compiler using Wine inside a fresh Docker image (Linux guest). I'm not sure how I could obtain more info on what caused both antivirus to trigger, but we'll look into it.

We use JUCE for building the app/plugin. It handles the GUI, the audio/MIDI devices and the plugin API. The synth engine was originally developed to run on a STM32F4 (what the Anyma Phi uses), so almost everything is purpose-built (with good old Makefiles). On the hardware, we use an immediate-mode UI and it's hard to go back to something like JUCE, which is flexible but a bit quirky. I often write GUIs with Cocoa for our internal tools (simulators, DSP models, etc) during the development of our hardware products and it's a much more comfortable environment.

In 2019 I had an early version of the Anyma engine running on Dear Imgui, it was really fun, but it would have required too much effort to properly manage audio/MIDI/plugin aspects in a cross-platform way, and the backends were incomplete at the time. JUCE was too much of a time saver to ignore for a team of 1.5.

I'm curious, if you don't use C++ and JUCE, what is your stack?

Thanks! Here are some links where you can hear/see it:

[1] Sound demo songs https://soundcloud.com/aodyo/tracks

[2] A short demo video https://youtu.be/jvHASVAGvhY

We're posting a short video presentation soon.

A DIY breath controller like you describe is a fun little project and adds a whole new dimension to your playing. Most wind synths expect MIDI CC2 for breath input.

It doesn't look like LLMS supports VST3 [1], but we had a report of the Bitwig Linux version looking for a VST3 bundle, the new recommended format, instead of a single library file with a ".vst3" extension, so of I'm wrong the issue could be that as well. Anyway, we're looking into building for LADSPA or LV2 for a future update.

[1] https://github.com/LMMS/lmms/issues/4715

I wrote an input service to improve the keyboard of the Titan Pocket[1], it's quite good for writing things. I've since sold it and tried a Jelly Star, which I returned.

The Titan Pocket is a nice phone, a bit too big and too heavy for me, but like most of the Unihertz offering the major pain point is that the stock firmware is old and not to be trusted, and the community-driven LineageOS alternatives are flimsy and incomplete. This is also due to Unihertz and Mediatek not doing their part and releasing the relevant source code or documentation for specific drivers/services. There is a small community with a few dedicated members but it's a bit of an uphill battle.

[1] https://github.com/oin/titanpocketkeyboard

I've been using Curio[1] for more than 10 years. The app is Mac-only but it is very reliable and regularly updated.

[1] https://www.zengobi.com/curio

  Location: Seville, Spain
  Remote: Yes
  Willing to relocate: No
  Technologies: C++, Objective-C, Javascript/Typescript, Python, Cocoa/AppKit, JUCE
  Expertise/interests: embedded development (STM32, nRF5, PSoC4), audio DSP, MIDI controller design, HCI (PhD)
  Résumé/CV: upon request
  Email: diademes_animisme.0l@icloud.com

I have 8 years of professional experience in electronic musical instrument design and development, and I did HCI research before that. I am looking for freelance/consulting work.

I have one! It's very good and you even helped me customize it further.

I'm working on a MPE MIDI controller with my friends at Aodyo. We've launched our Kickstarter last Thursday: https://loom.aodyo.com/en

This is interesting. Care to elaborate or share your script?

Absolutely awesome! I've long been attracted to tracker software but I could never find one that really makes me want to use it. Although this is browser-based, it might just be the one for me.

Something I would very much like to see in all music software, including this one, is an alternative for keyboard-based note entry and preview that is not based on the piano, but on the guitar/bass. Basically, each keyboard key is a semitone over the one on its left, and keys ZAQ1 are mapped to notes EAGD (when in QWERTY). It's very simple to do and I find it much easier to work that way, because it makes it very easy to play melodies and find note relationships the way you would on a guitar fretboard. No guessing where the black keys lie, most things are transpositionally invariant. I've made this into a macOS app and after more than 6 years using it, I find it vastly superior and much more adapted to the limitations of a computer keyboard. The fact the keyboard lines are staggered is annoying at first, but I've been quickly able to get over it. I guess all guitar players would find that useful as well.

Nice to see the Sylphyo mentioned on HN! (I'm the software developer at Aodyo)

To answer Jeff's post, in fact, the SWAM virtual instruments _do_ have a way to derive attack intensity from the breath signal. You have to explicitly select "Expression" for the "Attack Sens." parameter. You can also fine-tune the response using the "Auto Expression", "Expr. Trigger Mode" and "Expr. Trigger Sens." parameters in the Options. It's not the default behavior because many SWAM users play them using a keyboard instead of a wind controller, but it's definitely there. Obviously, our onboard synth does this automatically on our sounds, when it makes sense.

I don't know about Jeff's setup, but there's no need to add MIDI velocity on top of the breath signal[1]. When a wind controller outputs a MIDI velocity, it's just something derived from the breath signal, but it's best that synths just use the breath signal and produce attack sounds themselves based on that. That's what SWAM instruments do when "Attack Sens." is set to "Expression", and I'd say it's the correct way. If your wind controller outputs a breath signal at a high enough frequency (the Sylphyo can do up to 1 kHz), then there's enough information for the synth to produce an attack that really sounds like what the performer intended to do on the controller. On the Sylphyo, you can observe this with the onboard sound Meow[2]. Attacks will sound different depending on whether your attacks are done using the tongue ("tu ku tu") or using the throat, but the processing stays minimal so that any advanced technique (flutter-tonguing or growling in the video) can be faithfully retranscribed, and it works well with a subtractive/FM sound like Meow (it might be more difficult for physical models).

[1] MIDI velocity could serve another purpose in a wind controller playing a SWAM instrument: telling how hard you're pressing a key when changing the note, similarly to how flautists sometimes use the sounds of their keys clicking in their performance.

[2] https://youtu.be/UDcR4I1zatQ?t=33