SiLeMIMy approach
What if we could build the tools we need?
Two houses can be built from the same bricks and turn out very differently. We arrange the rooms around how we live. A few years later, we may enlarge a room, join two rooms together or give less space to a particular activity. We change the house because life inside has changed, and we can salvage some of the materials.
Tools that evolve with the way we work
I would like us to think about software and physical objects in the same way. An application could use a team’s own terms, read the documents it already works with and present information in the order it needs it. Two people doing the same job could start with the same functions and organise them differently. Each could revisit their tool as their way of working changes.
I work in sound, so I think of a mixing console. When I learn a new console, I learn where the manufacturer put the controls. Over time, those choices become my habits. What if I could start with my own movements? I could choose the audio resources I need, try a different fader layout, even set some controls at an angle because that is where my hand naturally finds them. I can imagine a workshop building that surface from a design I have already tried and later updating it while keeping the rest of the console.
Ready-made products will still have a place. I am interested in what else we might start to imagine. When we are used to choosing from what already exists, some ideas never occur to us. Being able to take a function designed elsewhere, adapt it and combine it with others changes what we dare to consider.
Rethinking the value chain
Imagine an idea giving rise to both the software and the machine it belongs in. We describe the task, the controls and the resources we need. We assemble what already exists, try a first version and make the missing pieces. We could design our own tools, make part of them ourselves or ask a workshop to build them.
Open source would play a central role. With code, plans and interfaces documented and shared under open licences, we could take an existing building block, modify it, combine it with others or merge two existing solutions. An improvement made for one tool could be useful elsewhere. A physical part removed from one machine could also find a use in another, provided it is compatible.
Workshops could use the same building blocks to make machines one at a time, on demand. In this model, value also comes from designing common components, adapting them to a line of work, making the machine that will actually be used and keeping it useful over time. Some activity could shift from producing batches in anticipation of sales to building and adapting tools for needs people have already identified.
A tool could grow as the work grows, then get simpler when the work changes. We could add or remove software functions, fit a console with extra controls or reclaim modules we no longer use. As with the house, the possibility of adapting what is already there would be part of the design from the start.
How I work today
I explore this approach in audio because I know the work and its constraints. I want to understand how the method could carry over to other fields. Today, I start with a practical need, look at what already exists and build a first version I can try. AI helps me design and develop. I set the goal and check the result.
It starts with a person.
I’m Matthieu Leroy, also known as Mamat. I have worked in professional audio for many years. SiLeMI/O grows out of real situations, repeated tasks and working methods I want to make simpler.
I define the needs, organise development and set the direction. Preparing a patch, transferring labels, finding a source or placing the right stage markers: each idea starts with a practical problem. My professional experience sets the course; it never removes the need to check the result.
Audio is my profession. Systems are part of my craft.
My background includes Radio France and international tours, including work across the Atlantic as a sound system engineer. These settings taught me to consider an installation as a whole and work with the real constraints of broadcasting and live productions.
Sound reinforcement systems, consoles, audio networks and technical preparation are my working environment. Understanding how these elements interact, anticipating difficulties and making an installation clear for the people operating it are also goals I bring to my tools.
Computing, networks and automation have been part of my work for many years. I like understanding what travels over a network, what a console expects, how an application organises its data and why an operation works — or fails.
I have also programmed for years, although software development is not my main profession. I have regularly created my own scripts, applications and automations to solve practical problems. These projects taught me to turn a need into behaviour and make different tools work together.
That background helps me ask useful questions and understand proposed solutions. Today’s methods let me go much further: they make possible applications whose complexity, quality and finish would previously have exceeded my own development skills.
Agents, models and orchestration designed around the project.
I design and run agent workflows: AI models combined with instructions, working context and tools, organised to perform defined tasks. The aim is to build a coherent process from requirements analysis through design, development and verification.
I distribute tasks across different models according to their capabilities, the difficulty of the problem and available resources. I define the context to pass on, available tools, validation stages and recovery steps when a result is incomplete or incorrect. Models can run locally or through remote APIs, depending on privacy, latency and cost requirements.
I use Hermes alongside local and remote solutions to assist with everyday work: monitoring relevant developments, sorting and summarising information, tracking projects and automating recurring tasks. I connect these tools to my own workflows, defining what they can access, which actions they can take and which steps require my approval. The choice of models and where they run depends on the task, the data involved and the resources available.
This orchestration relies on infrastructure I configure: workstations, GPUs, servers, networks and development environments. Where relevant, I also explore model adaptation through fine-tuning, including LoRA and QLoRA, with data preparation and evaluation of the results.
Using these tools well requires understanding their strengths and limitations: plausible errors, incomplete context, variable responses and proposals that can be difficult to verify. I keep goals explicit and check results through code review, trials and verification suited to the expected behaviour.
Modern tools open remarkable creative possibilities to anyone willing to learn how to use them. They make it possible to go beyond our initial skills and build projects that were previously difficult to complete alone. Professional experience, well-framed questions and sound judgement remain essential to turning that capacity into something useful.
AI contributes to building the SiLeMI/O applications and this website. I guide that work: defining what needs to be built, understanding proposed choices, checking results and deciding what is ready to publish. The process combines creation, learning and responsibility.
AI for development. Predictability for live sound.
In live sound, I look for speed, stability and behaviour we can anticipate. My aim is for the tools’ core functions to rely on code and explicit rules, without needing to query an AI model during use.
Models therefore serve primarily to build the tools: understand a need, design a solution and turn it into programmed functions. I favour repeatable processes that can be inspected and tested. This is a design requirement, not a guarantee of bug-free software.
Building, and learning as I build.
What excites me about this way of working is being able to create tools I could not have developed on my own. Professional experience helps me recognise what is needed; AI helps bridge part of the distance between an idea and its code.
It is also a remarkable opportunity to learn. I inspect the code, ask how a solution works, why it was chosen and where its limits are. Developing this way means understanding, trying things and revisiting what does not work.
I believe these methods allow many people to build the tools they dream of, even when creating them initially goes beyond their skills. That is certainly what they make possible for me.
Different projects. A common thread.
I work on several projects at once. You will therefore find quite different tools here, sometimes at different stages of development. Some address a small everyday frustration; others explore a much larger challenge.
What connects them is me and the world of professional audio. I start with needs that make me want to build something useful. Feedback from people who try these tools helps them improve.
If you have an idea, try bringing it to life. A small script that makes your day easier already counts as a worthwhile creation. You can also contact me to improve a SiLeMI/O application, share a challenge in your work or discuss a tool you would like to build yourself.
Your idea does not need to be fully defined. A real situation or repetitive task is already a good starting point. I cannot build every suggestion, but I welcome conversations and enjoy learning how other people work.
Closed source, deliberately flexible access.
My applications’ source code is not open. I have had bad experiences with my code being reused and my work commercialised without acknowledging its origin. That led me to stop publishing my sources.
I have nevertheless chosen to keep access to the suite’s applications as flexible as possible. Their functions remain available without a mandatory purchase. Licence prices are deliberately low and the system is deliberately undemanding.
StageFlow is free. StageDesk, StageMark and StageMon remain usable without a purchase: after 30 days, a support reminder appears at startup, and a licence remains optional. Dante Config Editor offers a full 30-day trial, followed by a permanent licence required to continue using it. Larsen Lupin also offers a 30-day trial, followed by a licence required for audio processing.
This flexibility is a deliberate choice: I prefer to rely on the tools’ usefulness and everyone’s sense of responsibility. Contributing supports development, fixes and maintenance; it also encourages me to continue and bring new ideas to life.
Nobody is obliged to contribute. Try the tools, use them if they help and share your feedback. Financial support is optional; a useful conversation can move the project forward too.
The environmental tension
Training and running AI models uses electricity and water, and making the equipment takes materials. I think the current race for computing power risks becoming environmentally unsustainable. More efficient models and models better suited to a specific task offer a way forward. The test is whether savings per use translate into lower consumption overall.
I can act on the way I design tools. Software we can revisit can stay useful when our needs change. An object we can repair or update piece by piece can stay in service longer. In the console example, I could rebuild the control surface and keep the audio engine and the inputs and outputs. I see a potential benefit if, over the whole time the tool is in use, we keep more parts in service and actually avoid making replacement equipment.
Try it yourself
The applications on this site are my first attempts at this approach. I invite you to try it yourself. Start with something you do over and over, a function you wish you had or a tool you would like to adapt. What would you keep? What would you change? And what would you imagine if you could build it? That is the path I am exploring with SiLeMI/O.