"nw_wrld" general discussions thread

[aagentah]

This is a space for the nw_wrld users to discuss the project, share work, and help each other.

What to use discussions for:

• Questions about modules, rendering, or the sequencer
• Sharing visual modules you've built
• Feature requests and ideas
• Performance setups and workflows
• Technical troubleshooting

What to use issues for:

• Bug reports
• Specific feature implementation tracking

Feel free to start a discussion or browse existing threads.

[aagentah]

@obrienciaran

Following up from #7

For sure! I'd love to contribute to this project but some guidance or a discussion here would be useful I feel. Otherwise I fear there may be more discussion like the decimal vs percentage one above :)

I see the roadmap has Signed and notarized macOS builds + signed Windows builds for frictionless installs so a product is on the way it would seem. As a first step to clarify, would you see this as being an advanced tool or simple tool in terms of complexity? i.e. do you know (or have hopes for) who your audience is yet?

That's great to hear. I'd love it if you'd be willing to contribute some things, and I appreciate the discussion so far.

Regarding the project's direction: many users will be relatively new to coding, often coming from tools like Touch Designer or having only basic programming experience. They're likely interested in creating their own audiovisual performances or exhibitions.

The open goal is to keep the experience of developing visual modules quite simple: when users select their modules folder, the code they write there can remain static & straightforward, with the SDK handling the underlying complexes of imports/base methods/asset pipelines.

As for the macOS and Windows builds, yes; those are currently in progress. The goal is a single-click installation experience so users can focus their coding efforts on building visual modules rather than wrestling with the software itself.

---

Let me know what you'd be interested in helping out on or what you'd personally feel the app could benefit from, and I'd be happy to help expand the roadmap based on that!

[obrienciaran]

That's all very clear, thanks for the detail. I also see potential here in keeping the process of visual creation quite simple. All tools out there (from my experience) are overly complex for the casual user. I've yet to find to one which is intuitive to use. In fact, literally all of the TouchDesigner gigs I've gotten have been from musicians or artist online who'd rather pay me a few quid for a 10 second Instagram visual instead of sinking hours into learning. I believe your tool fills that gap (and puts me out of work 😉 ).

Let me know what you'd be interested in helping out on or what you'd personally feel the app could benefit from, and I'd be happy to help expand the roadmap based on that!

Yeah that's a very good question! Basically right now, I'm taking a break from the corporate world to work on some personal projects, and also open source projects like this. Realistically I have about 2 months of freedom before I have to go back working for 'the man'. I could jump in and offer a little time on a few tickets here and there during that time.

I would propose that the visual part is fine for now - it looks great, and is comprehensive enough to keep people happy. Therefore this could be an opportunity to work on extending basic functionality or working on stability. Off the top of my head, what could be nice is a functionality to set the visualisation window to 9:16, or 16:9, for example, with the visual elements automatically resizing. Then an additional file -> export -> export as .mov functionality. As I mentioned, all of the people who write to me re: TD are doing so because they want videos for Instagram or Tik Tok, so this would satisfy this need. This comes back to the question of defining who the users are. The functionality I mentioned might cheapen the brand, so to speak, if the visuals end up all over TikTok and not art galleries. At this point, and as @Shreyas-Walde mentioned, I think the most important thing is talking to people to find out what they want; and also 'internally' discussing who the users are. Personally I think it's very easy for us engineers to just build build build, but it could be useful to take a step back and define this a bit more. I'm also happy to jump on a call if you want to tease this out!

I really appreciate you open sourcing this, and having public discussions. Great work to-date on this tool. Its fantastic!

[Shreyas-Walde]

Well said, I really believe this project has true protentional (just an intuition but I still believe it).
I want to everything I can in order to contribute to this project.

@obrienciaran I really like your profile, specially your music (I can imagine your music and @aagentah visuals) "The concrete will be a blast" a concrete for people in Tech. I know I'm taking this too far, but i dont wanna kill my inner child imagining, thinking about such a future, if this happens I would on cloud 9. And your artworks too reminds me of "NeoRetro Japan" + "90's Japan aesthetics" looks awesome.
I would really love to join in the call with you and @aagentah discuss more and make it true.
This is so interesting.

[aagentah]

I'm taking a break from the corporate world to work on some personal projects, and also open source projects like this. Realistically I have about 2 months of freedom before I have to go back working for 'the man'. I could jump in and offer a little time on a few tickets here and there during that time

Bravo! Would love to hear more on what you have planned?

Similarly got a chance to check out some of your music, very cool stuff. I was at Dekmantel maybe 2-years ago and met a bunch of friends in that minimal techno space. It's also quite popular here in Manchester atm.

Therefore this could be an opportunity to work on extending basic functionality or working on stability. Off the top of my head, what could be nice is a functionality to set the visualisation window to 9:16, or 16:9, for example, with the visual elements automatically resizing. Then an additional file -> export -> export as .mov

Honestly, that feature sounds very handy. I'll admit to having screen-recorded many scenes and having to crop it in Premiere etc, and I appreciate that in the current era, any convenience for sharing visuals is a big win, even if, like you mentioned, it's not strictly related to performing live (that's okay in my opinion).

If you'd be interested in taking a stab at the feature, I'd be quite grateful. It might be a good jumping-off point.

[obrienciaran]

Thanks @Shreyas-Walde , I really appreciate it. I'm glad you saw my influences in what I make too!

Would love to hear more on what you have planned?
My background is in AI research/data so I'm doing some work on small language models from a privacy-first perspective. I'm trying to tie in an artistic angle as well and develop some algorithms to protect artists work, kind of like digital copyrighting embedded into images.

Also thanks for checking out my music. I make a lot of electronic music both out of pleasure but also convenience of being able to work on my laptop. Then also a lot of non-electronic music when I have time to meet others and play together. Super cool that you made it to Dekmental. It's always a great time at that festival.

If you'd be interested in taking a stab at the feature, I'd be quite grateful. It might be a good jumping-off point.

I guess the best place to start would be creating some issues on the board? Im conscious of jumping in and building too soon, without careful planning.

I see you also mentioned below: "...identifying any bugs in the code, opportunities to clean up the repository, any methods or value sets that may be inconsistent, and general front-end cleanups." I agree this would be the most sensible place to start.

[Shreyas-Walde]

Thank you @aagentah for open sourcing this projects.
This seems quite fascinating and really interactive use case to actually see the program we code, as you mentioned earlier "many users will be relatively new to coding" but what i think projects like this gives us the "new programmer" a motivation drive to keep doing and earn how to scale and make project from absolute zero. Times like one feel completely lost.
To start with contributions, I'll first talk and show some of my friends and people I know who are DJ and do concrete, how would they feel, understand a bit.
and learn the technology used in this and start to contribute myself.
again Thank you so much for giving us, specially me the opportunities to witness such project exists in open-source.

Also I would love to take your opinion and advice on how can I the "new programmer" help you, I mean literally help you in something, from docs to code anything which you feel or need help me. I'll do my level best.
I'm new but a quick learner. Try me out!

[aagentah]

And thank you for being here!

Really appreciate your optimism in this space. It's much needed. And would love to know a little bit more about what you've been working on in the meantime. I had fun checking out your Github and recent explorations.

Also I would love to take your opinion and advice on how can I the "new programmer" help you, I mean literally help you in something, from docs to code anything which you feel or need help me. I'll do my level best.

That's great, and I'd really appreciate that. Any support is welcome!

Considering the project just launched and we're currently in beta. I'm committing the next couple of weeks to stabilising the software as much as possible. That means identifying any bugs in the code, opportunities to clean up the repository, any methods or value sets that may be inconsistent, and general front-end cleanups.

There's really no end to what could be done here. It's just a matter of identifying all these different caveats and then incrementally improving it over time.

The current roadmap has some pretty big features, including ones that I consider too big to embark on before launch, so I probably wouldn't recommend much off there, especially whilst we're in the current period.

If you wanted to share some more background or what specific areas you're interested in, maybe we can work out a smaller set of features or cleanups that might make sense?

Thanks again for being here <3

[Shreyas-Walde]

Thanks @aagentah for the detailed guidance! I really appreciate you breaking this down so clearly.

Here's a bit about my background: I've been learning Python and building projects that excite me I gained a rough understanding of how AI-driven projects are made, what AI wrappers are, and programming fundamentals. However, I realized I'd never built a full product or something for regular users who can just start using and understand it.
To tackle that gap, I've been learning backend development how APIs work, how to build them with FastAPI, and how to work with them. I've also learned how projects are pushed to production and containerized. I'm comfortable with cloud infrastructure (AWS, Linux, and Docker).
I'm on the verge of diving deep into JavaScript and React this project is great motivation. Honestly, I find frontend skills harder to grasp, but I want to understand this project inside-out, so I'll learn them regardless!

I tried setting up this project on my local machine (both Ubuntu and Windows using WSL), and it was straightforward. I'm now understanding the project better and reading through the docs.

What would be the best starting point for me?

Looking forward to contributing! <3

[aagentah]

@Shreyas-Walde that's amazing congrats on getting so much traction so far. It's an interesting time since all this stuff has never been so accesible and it's wicked to see so much developing interest emerging in recent years; I think the general impression from non-tech people is that AI tooling will evidently reduce the number of those pursing this stuff. And whilst it might make traditional corporate 9—5 jobs a tougher market (especially on entry), the creative arena is absolutely booming.

Have you got any longer term plans for future projects? :)

If you're coming from a more backend + Python background, you'll definitely have no issues with working on some JS projects.

Thanks for trying out the repo too.

As @obrienciaran and myself were just discussing, I think the next few weeks look like overall stabilisation of the repo. Right not I'm working to migrate typescript and runtime testing carefully into critical areas.

Whilst that's happening there's not a whole lot of "exciting" bits to work on I'll admit; but if you're up for it and up for some small contributions, I'd love a hand with some of the ESLint warnings that have been stacking up in the app.

Feel more than welcome to have a stab at cleaning some bits up :)

If you branch off from develop onto a new branch, feel free to put some PR's in place (ideally in smaller chunks).

Hopefully in the coming weeks there'll be some wider discussions about new features and the future of the project!

Gimme a shout if you needed anything.

[henjolo]

Unbelievably excited about this project. Presently manipulating geometry and .obj files with glee. Thanks again :) Very interested in supporting this project.

Couldn’t find any mention of MIDI Control Change (CC) support in the repo (perhaps architectural reason?). Is there an intended path for handling continuous control data? For example, mapping knobs/faders to method parameters at control rate. If native CC handling isn’t planned, would converting MIDI CC to OSC externally be a way to approach this within nw_wrld’s architecture? Curious how you’re thinking about continuous control vs trigger-based control in the system.

Simple but fun edit of the geometry module, adding displacement method DisplaceGeometry.js

[aagentah]

@henjolo thank you! nice to hear you're having a play around with it :)

Couldn’t find any mention of MIDI Control Change (CC) support in the repo (perhaps architectural reason?). Is there an intended path for handling continuous control data? For example, mapping knobs/faders to method parameters at control rate. If native CC handling isn’t planned, would converting MIDI CC to OSC externally be a way to approach this within nw_wrld’s architecture? Curious how you’re thinking about continuous control vs trigger-based control in the system.

You've raised some great points here, and I'll admit part of the reason the app doesn't support continuous control messages is that I've always preferred a trigger-based system to a continuous parameter modulation system. With that said, I can absolutely see the use case for this. Wanting to control a method parameter from a fader is obviously quite common with other software.

Current Architecture Limitation

Currently, methods are triggered with pre-configured parameters set in the dashboard. When a channel fires, it executes methods with static parameter values. There's no mechanism to:

• Receive CC messages
• Map CC values to method parameters dynamically
• Update parameters continuously based on input

What would need to be true in order to support this

Since all of the current methods are designed with triggering in mind, there would have to be a real-time parameter binding layer for all these methods and functions to support CC values like you mentioned; and then offering a "continuous control" version of the existing parameter system.

Alternatively, the methods for visual modules would be split into two categories: trigger-based and continuous control-based, which obviously adds more overhead, not just for the software and its starter modules, but for people getting into this space. Definitely something to think about.

If enough people were interested in this as a feature, the software could realistically support it.

Maybe something that is raised on a Poll? :)

[henjolo]

Yes so not a minor feature to implement then. Top of my features wishlist for sure. Poll sounds great.

[aagentah]

@henjolo thanks! Poll/Discussion opened: #16

Let's give it some time and see what people come back with :)

[aagentah]

@henjolo

Simple but fun edit of the geometry module, adding displacement method DisplaceGeometry.js

This is great; would be a pretty cool addition to the Three.js base methods in general.

If you wanted to implement it here, feel free to open a PR and we can get it in :)

https://github.com/aagentah/nw_wrld/blob/main/src/projector/helpers/threeBase.js

Some parameter ideas that would be cool:

• Placement direction (number between 1-360)
• Duration (ability to control speed of displacement)

[henjolo]

Im looking at this, getting a bit familiar with application source structure.

Think we need a few things:

1. store current position (so it can revert)
2. Direction THREE.Vector3 (built-in Three.js class representing a 3D vector (x, y, z)) (base = some nonzero value so you can see it)
3. Magnitude / distance (base = some nonzero value so you can see it)

I wont do duration for now to stay consistent with other base methods; temporal control is handled by the sequencer or externally? - but i could see this being a future universal animation helper so you wouldnt need another channel to reset a parameter when designing modules in tracks

[aagentah]

Sounds great; feel free to get it setup and implement a PR!

[brunol97]

Hi,
@aagentah I read through the roadmap and saw this:
Remote API input source with HTTP/WebSocket client for cloud-based services (audio analysis APIs, ML models, etc.)

I work as a Python-based ML/AI Engineer so think this would be cool to look into. However I don't have a background in audio/visuals. Could you maybe share your thoughts on a specific use-case so I can look into what models and functionality is required for that?

[gorhgorh]

Websocket also offer new input types, like people in the concert generating data via accelerometer and such so we have input sources not only from the music, but also the audience

[aagentah]

@brunol97

Hi both, and tysm for taking some interest here.

As eluded to, that we'd want to open up the input layer for the software where possible, whilst keeping what nw_wrld really cares about (track selection, and method triggers) agnostic. @gorhgorh mentioned a web-socket which is perfect, and a cool use-case.

Some immediate ideas below (would love to hear your thoughts)

A native “Remote API / WebSocket” input could be implemented as a first-class input type (e.g., remote) that maintains a WebSocket/HTTP client connection and normalizes incoming messages into the same two internal event types the app already uses: track-selection and method-trigger. This keeps the existing mapping/trigger pipeline unchanged while adding a new transport.

Example WebSocket payloads a remote service could send:

{
  "type": "track-selection",
  "data": {
    "track": "intro",
    "timestamp": 1730000000.0
  }
}

{
  "type": "method-trigger",
  "data": {
    "channel": "energy",
    "timestamp": 1730000001.2
  }
}

And a minimal Node/Electron-style WebSocket client that converts these to internal triggers:

const ws = new WebSocket("wss://example.com/nw-wrld");

ws.onmessage = (evt) => {
  const msg = JSON.parse(evt.data);

  if (msg.type === "track-selection") {
    // internally: select track by name
    // e.g. emitInput({ type: "track-selection", data: { identifier: `/track/${msg.data.track}`, ... } })
  }

  if (msg.type === "method-trigger") {
    // internally: trigger channel by name
    // e.g. emitInput({ type: "method-trigger", data: { channelName: `/ch/${msg.data.channel}`, ... } })
  }
};

A use-case example: devices stream sensors to a server, the server aggregates them into higher-level signals (e.g., crowd “peaks” or thresholded events), and the app receives those as method-trigger/track-selection messages over WebSocket.

Something to note

In order to accurately map specific "intensity" of a crowd to be used as more of a constant, requires something akin to CC data and variable input instead of the current "trigger-based" approach (there's a relevant Poll open to discuss that one specifically #16)

Would love to hear your thoughts.

PS: Feel free to open this as a separate discussions thread if the three of us want to explore it further :)

[gorhgorh]

I missed your answer sorry, was preparing for a gig and switched to music mode :)
The use case you mention is exactly the way I'm planning to build, averaging the input is out of scope and can be made on another machine / process, so a cc like support would be nice.
If you need input / test / help on the websocket part let me know then i'll open a thread.

[aagentah]

I missed your answer sorry, was preparing for a gig and switched to music mode :) The use case you mention is exactly the way I'm planning to build, averaging the input is out of scope and can be made on another machine / process, so a cc like support would be nice. If you need input / test / help on the websocket part let me know then i'll open a thread.

No apology needed, and thanks for the continued interest. Yes, absolutely. This week I'm planning on doing another big release, which pushes a lot of refactors and also a new input source type, which will essentially be a multi-band audio at the track level. Maybe once that's all going on, we could hop on a thread and discuss something regarding a WebSocket. I think that would be a really cool feature :)

@gorhgorh

[eoinohal]

Hi @aagentah,

This is a very exciting project, I really love the vision.
I noticed the "Multi-band audio threshold analysis" item on the roadmap and think it’s a really cool feature. I've been playing around with a setup in a fork with a similar goal, using a virtual audio loopback driver to pipe system audio directly into the app.

I'd love to hear more about your architectural plans for this feature.

[aagentah]

Thanks for the kind words. I'm glad you're enjoying the project :)

Definitely, I could probably share a bit of info on how this would all work. However, I should say there's already an early implementation of this on the feature branch. If you waned to get it up and running on your own, have a play around.

It's certainly nowhere near ready to be merged, but any early feedback would be amazing.

The general idea here is it could simply track on-device audio and split it by frequency into three separate channels: low, medium, and high.

An additional implementation here might be allowing the users to upload their own audio files, so it doesn't technically need to be on-device audio; it could just simply be played from a file somewhere. But that might have to come later on.

Branch in question: https://github.com/aagentah/nw_wrld/tree/feature/system-audio-input

Would love to hear your thoughts!