Interview with Ranjith Hegde, Developer of MayaFlux.

Ranjith Hegde traces his journey from late-beginning violinist to creating production audio for Metro VR Awakening and developing MayaFlux: a radical open-source framework merging audio, visuals, and control without traditional interfaces. This interview by Anugrah, a Research Associate at TheISRO, reveals

how gesture-tracking, live coding, and embracing computational indeterminacy reshaped his artistic practice across Sonology, corporate game audio, and interdisciplinary performance.

This excerpt maps Hegde’s chronological and creative evolution, focusing on his late-beginning

relationship with the physical demands of classical music and his subsequent navigation of technical constraints. He discusses the bodily friction that forced him to view programming not

as a replacement for human performance, but as a tool to expand and extend physical gestures. The conversation details his time designing complex spatial audio ecologies for corporate virtual

reality pipelines (Metro VR Awakening) and introduces how navigating the deep, fragmented silos of game engines ultimately drove him to envision a singular, unified pipeline for sensory

data. It concludes with a deep exploration of working with timing, asynchrony, and embracing the pattern-breaking chaos of human perception.

Anugrah: First off, what initially hooked you on to sound in your early years, starting from studying violin and then moving into electroacoustic experimentation and programming? What specifically sparked that transition to working with code?

Ranjith: Compared to most people who study violin, it came very late in my life. Regardless of whether you study Indian classical, European classical, or whatever else, the idea is usually that you start younger so that your body develops with the instrument. When you're older, you have both physical and psychological baggage that you need to undo if you want to begin seriously with an instrument. If the goal is simply to have fun with the instrument or play with friends, that doesn't matter as much. But if you want to take it professionally, those

things become important. I began with sound almost completely by accident. I was put into the marching band when I

was in boarding school, and they made me learn trumpet. The school had these small tubes with notations written down, and there were about twelve different instruments in the

marching band. I was fascinated by the idea that I could read something and then play it back, so I just learnt all the instruments they had to offer. Violin came much later. I was around sixteen, maybe sixteen and a half, when I decided to see whether violin could be interesting.

There was no special reason. I just picked it up, tried it for a while, and felt that this was something I could spend a lot of time with. It did not feel like something that would be

exhausted once I had played the tunes I already knew. It felt like something that could keep me invested for a very long time.

After college, I went to Chennai to study music directly. I joined a conservatory there that had just started, and I was in its second year. But after a year, I realised it was not for me,

because it was focused primarily on the film industry rather than on music exploration as I imagined it. So I found tutors around Chennai instead. My main instructor was a German

musician called Holger Jetter, and we have stayed in touch for many years. He taught me not only sound, but also aesthetics, philosophy, and art more broadly. Coding was not part of my

life for a long time. When I went to the Netherlands to explore what electricity and electronics could do for my artistic practice, I found the tools on the computing side

interesting, but in the beginning I was more drawn to the electrical side: circuit boards, oscillators, filters, and things like that. You could build the circuits you wanted and create

something that you simply could not produce acoustically. That was very fascinating. Coding happened differently. I thought, if I now move into computers, what else can they do?

To my surprise, the move from acoustic to electric had felt much more liberating than the move from electric to electronic. The same liberation was not there, because the tools I

encountered in electronic music, or at least the ones the community at large tended to use, felt like very direct mimics of electric or acoustic systems. That is when I thought that maybe, if I learnt programming, I could push beyond that. That is how I ended up in computing. It was almost completely accidental.

A: So when gesture tracking and audio code first made sounds feel truly alive and responsive, what was the biggest surprise you encountered during that process?

R: This was part of the journey I mentioned. In Chennai, I was part of a group called Basement 21, and the primary idea there was that we explored together regardless of what

discipline we came from. So you might have a painter working with a sound artist, or a sound artist working with a dancer or movement artist. The effort was always to make sure that, if I

entered the space, I was not entering simply as a sound person. I had ideas in sound because that was my training, but the point was not to remain inside the things I already knew. I

wanted to learn from the other person. If I was working with a dancer, for example, they understood space in a way I could never

understand purely through sound. For me, space in sound has often been about placement. There is a lot of research that makes this more nuanced, of course, but broadly it is still about

placement. For a dancer, space can be about equilibrium, spatial tension, weight, relation, and many other things. Learning how a dancer thinks, to the best of my ability, or learning how a

painter thinks about composition and placement, opened up ways of thought that I could not reach through violin alone. When I began exploring computation, I found that limiting in one

sense. I was asking myself how to read those kinds of insights computationally. If I had learnt something from watching a dancer, how could I translate that into electrical or electronic

systems? That was tricky. At the same time, the cameras available for tracking did not initially seem very interesting, because they only did, badly, what my eyes could already do.

They did not offer new information. So I started asking what I could do that I could not get before. My eyesight already tells me

where a person is in space. If a camera only reproduces that, it is not yet very useful to me unless my eyesight is poor. Then I encountered tools like Kinect and Leap Motion. They

build skeletal structures of the body and give you data based on that. That interested me more. Even then, I thought, this still gives me position, which I can already perceive. It was

not enough yet, but it was the right direction, because now I had data my eyes could not measure precisely.

From there, I started asking what I could do that vision alone could not do. Suppose a dancer I work with has certain tendencies. They tilt their head a lot, or they favour one corner of the space. Computationally, I can track that. I can set a timer and ask how often they go there, or

how long they remain there. Then I can connect that with another parameter, like how often they turn their head. Computation allows me to combine those values into a new relationship,

something like a two-dimensional value or an emergent pattern, and work artistically with a relationship that did not exist for me before. If that relationship only exists in my head, it is

not very interesting. But if I can record it and use that data to generate sound, visuals, or some other material, then it becomes powerful. That was the important aspect of gesture

tracking for me. It made many parts of a person's behaviour, and many aspects of their tendencies, available for artistic interpretation in ways that are very difficult, or practically

impossible, to achieve physically.

A: It is very interesting how you seem to embrace complexity in order to open up possibilities

for your craft and practice. Moving to one of your projects, Metro VR, how did creating movement, sound effects, and music for that differ from your earlier experiences in improvisation and other group work?

R: It was an entirely different experience because, for the first time, I was in the corporate world and had a career role as an artist within production. That was not part of my training. I

had done performances for corporate contexts before, but those were always limited in time. You have a contract, one night, or one event. It is not the same as being part of a production

team. In a production environment, especially a corporate one, the group is not just you and the people you are artistically collaborating with. It also includes the people who pay for it,

the people who fund it, the marketing team, and many others. So understanding that the task in front of me already had its limitations and possibilities mapped out was the first thing I had

to come to terms with. At the same time, it was fascinating. I had always felt games were an interesting area to

explore, because they contain many aspects that other art forms do not hold together at once. With painting, you have time in the sense that you can spend as long as you like with the

work, but the work itself does not change over time. Your interpretation changes. In dance or movement, you do not have the same freedom to freeze time and explore a moment in depth.

With sound, too, you can place a speaker in space, but you cannot easily move through that space in the same way unless a specific technology allows for it. Games offer all of this

together. You can spend as much time as you want with one aspect, combine it with others, and move within a designed environment that still allows for exploration. It can be both

curated and open-ended at the same time, and that is difficult in other domains or domain combinations.

When I was offered the chance to work on a game, I did not know at first which game it would be. At that point I was working with physical modelling, and the company thought

what I was doing there might be useful. When I joined, I realised it was a VR game, and they wanted both physical modelling and spatial thinking because, in VR, immersion is fundamental. Without immersion, it becomes difficult to justify the medium. If all you are doing is what a normal game already does, but with something heavier on your head, then

why would anyone care? My focus became: which sounds are necessary, and how can they remain convincing within

the limitations of the platform? VR headsets have a very small computational budget. In fact, many mobile phones have more powerful CPUs than VR headsets. So optimisation becomes

crucial. In an ideal case you might want hundreds of sounds at once to make an underground environment feel alive: train tracks screeching, people speaking in the background, fragments

of conversation, ambient textures, and so on. But you cannot have all of that because of memory and processing limits. So a large part of the work was figuring out which sounds

could be reduced while still remaining recognisable, and how many could exist at one point in time. Alongside that, there were the more concrete interaction questions: how do footsteps

become more interesting, how should objects sound when picked up, and so on. In VR, people will pick up objects, so those tactile interactions matter. On the product side, you are constantly trying to understand the whole experience. You keep

playing the game over and over in different environments, with every new feature, to understand what effect it has. On the engineering side, we also had to work a great deal,

because Unreal Engine's built-in audio tools are only serviceable. The assumption is often that people will import middleware and handle the audio there, so the internal audio pipeline is not especially strong. We had to write many new systems to make the results we wanted possible. One of the things we implemented was dynamic music, where every player action

that affected the game also changed the music in some way. I do not mean swapping in entirely new compositions. I mean adding new layers to the music based on what was happening in the game. Because the game is not deterministic and we do not know what the

player will do next, you need many systems sitting there, ready, listening and polling for possible actions, so that they can trigger the appropriate musical or sonic events.

So it was very different. I had to think much more directly as an engineer and only indirectly as an artist, though of course I was still contributing to the larger artistic world of the game. It

was educational, sometimes frustrating, but overall very worthwhile.

A: And in another project, MayaFlux, where audio and visuals mix seamlessly without traditional cables, knobs, and similar interfaces, how did that free up, or perhaps constrain,

the sounds you were able to create?

R: It is interesting because MayaFlux itself was almost accidental. What exists now is what I

have been working towards for about fifteen years, but the specific path that led to it was a fluke, to be honest. I was teaching a class at a school, and a few students wanted to explore

audio beyond what we were already teaching. They knew my practice and wanted to go further. So I was teaching them OpenFrameworks outside the course. OpenFrameworks is another toolkit, similar in some ways to what I am building, but at that

point it was already becoming dated because many of the tools it relied on were deprecated or disappearing. While teaching it, the students kept saying that audio was too difficult.

Graphics felt easier because tools like p5.js had made them accessible, whereas do-it-yourself audio still felt hard.

So I thought, let me do a live stream over a weekend and build an entire audio engine from scratch in one day, just so people can see that if I can build a whole engine in one day, then

students can spend a few months exploring what they want. It is not that audio is inherently too difficult. It is just that it has not been explored and taught in the same way.

Building that engine in one day gave me the idea that C++ had improved quite a lot in terms of usability compared to when I first learnt it. That is when I thought, let me write something.

But once I started, I did not write anything simple for a couple of months, because I realised this was an opportunity to build everything I had ever wanted from computing. That is where

the current effort really began. One of the core ideas was to explore what the digital truly is. This is something I discussed in the C++ conference talk I gave. One thing I said there, which was not especially well received because it is somewhat inflammatory, is that computing as we teach it is primarily

vocational. You are taught to use tools. You are rarely taught to question them. You are not taught to think about computing itself.

If you look at physics, you are not simply taught to use a machine. You are taught to consider the properties of physical systems, to question them, and to experiment. There are many

recognised avenues of exploration. Computing is generally not taught that way. Usually someone gives you a brief and asks you to build a tool. So there is very little widespread

inquiry into what computing could do that we do not already have.

That also means we have not spent enough time engaging with what the digital is aesthetically, interactively, or conceptually. If you think about a piano and ask how to make it

more visual, you quickly run into the instrument's physical reality. The more you open it up or modify it visually, the less it remains sonically what it was. That limitation is real. In some

cases it is interesting, but it is still a limitation.

In computing, by contrast, a video is a large number of pixels updated at a rate that makes our eyes think there is motion. Sound is a stream of pulses sent to a speaker so that the air

vibrates and we hear it. All of these things can be generated at the same time. One function can generate both sound and visuals. So the reason we separate them is primarily because we

are mimicking the camera, the microphone, and the screen. We are not thinking about what the digital can be in itself.

We have spent enormous effort recreating the limitations of physical devices in digital environments without asking what digital systems can do beyond those limitations. If a

physical camera cannot do something, there is a good chance your camera app cannot either, not because the computer is limited, but because nobody has thought beyond the physical

model. For me, that was the opportunity: if we stop recreating what we know and instead begin from zero, what becomes possible?

In order to get sound and image, yes, eventually I need to send twenty-four frames to the screen and forty-eight thousand samples to the audio card, or something in that range. But

that is a constraint of output. That decision should happen at the end, when something goes to the screen or the speaker. It does not need to structure the beginning of creation.

If you look at something like Processing or p5.js, they have a draw call, a function that runs at a frame rate. The problem is that the needs of the screen become the user's problem. But

the user should not be responsible for providing twenty-four frames every second. The user should be able to provide what they want, and the computer should present whatever is

appropriate. That was one of the primary things I wanted to explore. If I am not forcing computing to look like what its outputs expect, what becomes possible?

At the end you decide which subsystem runs a particular function. If the video subsystem runs it, maybe the data needs to be interpreted in a form the video system understands. But that decision belongs to the presentation layer, not the artistic layer, not the creation side. That is where my focus is at the moment: you write a simple function, and then you decide

later what to do with it.

A: Across your projects and the experience you have gained, could you point to one or two

techniques, perhaps physical modelling, gesture-to-sound work, or vowel extraction, that

have most reshaped the way you listen to the world around you, and why they had that impact

on your listening practice?

R: What I am about to say is really an evolution of something I had observed since I was

younger, but when I was young, I did not have the tools to articulate it, or even to know that

it was worth investigating. Over the last five or ten years I have become able to put it into

words, and what struck me most is that everything around us is not linear. Unless we are in

controlled environments, almost nothing is linear. Things are always asynchronous. More

importantly, things do not operate through the assumption that everything has a linear

interaction. But we build the world around us expecting one hundred per cent controllable,

fully automated linearity, and that causes many failures.

I explored sound in the same way. If I stop worrying about the linearity of a particular

musical tradition, I see that even what we think of now as a fixed musical moment within

traditional music is actually part of a continuum developed over centuries. We isolate it and

study it linearly, but if you allow it to remain what it is, you absorb much more. You open up

new ways of conversation and interaction.

I had the same experience while working with dancers. If I am too bothered by the idea that I

am entering as a sound artist, then I am not doing justice to the collaboration. Dancers think

through things that I cannot think through with my instrument, or at least not easily. If I am

open to that, if I am open to the possibility that what I know is only a subset of things and not

something comprehensive, then new ways of thinking open up.

That also applies to identity. If my identity is not simply, "I come from this, therefore I am

this," then I can explore more. I stop saying, "This is not my domain" or "This is not my

concern." So overall, the important thing for me has been an appreciation not just of

asynchrony, but of what we might call indeterminacy. Truly believing that things are random,

and that we form patterns because as humans we are good at forming them. Those patterns

make us comfortable, but they are not necessarily really there.

If you realise that, so much of the world opens up. That has been the one constant throughout

everything I have done. Accepting and appreciating indeterminacy, noise, randomness,

whatever term one uses, opens the world in a way that expecting linearity never can.

That idea carried me through different projects, different mindsets, everything I explored.

Once you open yourself to it, you make connections that are not otherwise possible. You may

suddenly feel that what you are doing as a programmer smells like something you ate

yesterday, or resembles some childhood experience. There are too many connections to make

if you see everything as part of a continuum rather than as isolated categories.

Those connections may only be temporary. Tomorrow morning you may think the idea was

foolish, and that is fine. But being open to the possibility that things are connected, whether

temporarily or otherwise, is central to how I work, how I create, and how I think about tools.