Polywell: a text editor component

[zorg]

The older trackers might not have had this stuff, but as far as I can tell most of the newer ones will host whatever the standard format is on that platform. Some even have wrappers, so they can become like a sequencer/sampler plugin for another host.

True, even OpenMPT allows VSTs via its own format, but i wouldn't strictly call stuff like renoise trackers anymore. Tracker-esque DAWs, yes.

Anyway, I'm not suggesting the DSP stuff has to be plugins, but it would be nice to have at least some effects like frequency filters, reverb, delay, compressors, tube distortion, etc. It would also be nice to have at least one synth (think GoatTracker) and one sampler (think FT2).

Agreed on synth and sampler, disagreed on the rest; reverb can be emulated with two slightly delayed channels playing the same notes, with different volume/amplitude (sacrificing a second channel/voice for it of course). Freq shenanigans were usually sidestepped by having a long sample that did a freq. sweep itself and changing the offset positions. Compressors were not needed since you actually needed to not suck at mixing 4 voices. This is for old trackers though, not necessarily for what could be implemented here.

I suppose you could go the oldschool tracker route and not have any fancy DSP, but it's going to limit how your compositions can sound (they'll sound like mods from the 90s, or C64 chiptune, basically... but maybe that's the idea).

I thought limitation was the point... that said, with a sampler implemented, one can use non-chip-esque sounds as well. mods from the 90s would be appropriate, though that also depends on the instruments used, and the effects supported. It's mesmerizing how different the same track can sound across various sequencing solutions (i.e. sound chips, or sample banks), like the Monkey Island OST, for instance. Playlist including 8 devices

How can we contact each other and draft some ideas around this in order to get something started?

I'm okay with most ways of communication. (except skype) IRC, Discord, something else?

[Positive07]

Well lets create a Discord text channel and a Github organization if everyone is fine with that

Edit: Slack may be better suitted though, with Github intgration and all

[airstruck]

Agreed on synth and sampler, disagreed on the rest; reverb can be emulated with two slightly delayed channels playing the same notes, with different volume/amplitude (sacrificing a second channel/voice for it of course). Freq shenanigans were usually sidestepped by having a long sample that did a freq. sweep itself and changing the offset positions. Compressors were not needed since you actually needed to not suck at mixing 4 voices.

I guess this is the thing that always bothered me about the old trackers. You're right, you can do a lot of this with preprocessing, but it's an entirely different workflow. For an all-in-one tool, I'm not sure I like the idea of leaving the tool to pre-process a bunch of samples. In particular, for the synth part, you'd really want real-time effects unless you want to bounce synth output to samples, pre-process that, and then pull it into the sequencer (unless the relevant filters/effects are actually part of the synth... but then you might as well make them separate so you can use them with the sampler).

For some things, preprocessing isn't just a more awkward workflow, it's really not a viable option. Imagine a long acid house / minimal tech house track (think Richie Hawtin or Frankie Bones) that's basically a few patterns on a 303 and a drum synth. Slow adjustments to the cutoff and frequency of the LPF on the 303 really make the whole track. To preprocess that, you'd need to have a loooong looped sample and put all your filter sweeps and stuff on it, and then pull it into the sampler. More advanced stuff like side-chaining (progressive trance) would be a complete nightmare to try to pre-process. Layered percussion and stuff (breakbeat / hip hop) would be alright to preprocess, but I wouldn't really want to leave the all-in-one tool to do it.

I thought limitation was the point..

If that's the case then yeah, you probably don't want any fancy DSP effects. Curious to see what Technomancy had in mind here.

[technomancy]

I thought limitation was the point..

If that's the case then yeah, you probably don't want any fancy DSP effects. Curious to see what Technomancy had in mind here.

TBH I haven't really thought through the implications on the music side much. I think the limitations are a big part of what makes Pico-8 work, both in terms of the appeal of the aesthetic and making it easier to implement. But I strongly disagree with some of the limitations Pico-8 puts on the code for the reasons explained here about how it results in forcing you to make your code worse: https://eev.ee/blog/2016/05/25/under-co ... co-8-game/ (shortening local names; needing to do foo_bar instead of foo.bar to appease the token count limitations)

The aesthetic angle of the lo-fi style is cool, and I think it makes things a lot of fun. But mostly to me the limitations are about making your goals actually achievable. To me, writing a general-purpose graphics editor inside love seems unrealistic. Likewise with a general-purpose audio composing environment! And then on the other side too, as someone who is using the tool to develop a game; they are more likely to actually finish if they use pixel art and simple chiptunes, because those are the kinds of things that one person or a small team can produce decent output with without sinking a ton of time into it.

I don't know if I have enough context to say which approach is better-suited here for music composition. Basically, whatever is realistic to implement wins, as long as it is still approachable for those creating games. Remember that folks who need more power or customization can always fall back to external tools. Being an all-in-one tool doesn't have to mean one-size-fits-all, just that it's a good place to start. If someone has really specific requirements around what they want the music to sound like, it's likely they already know how to use another music program, and they can just skip the included music tool altogether.

Also: wow; I didn't expect this topic to raise so much interest; this is great.

[Positive07]

Yes I also think limitations aren't bad, there are other programs that may suit more specific needs so we better start small, having a good code base will allow to iterate quicker and add more features along the line, having too big of an objective won't let us focus on what is important and we may not get anything finished so we better decide on basic features and we can later expand.

I have no idea about sound, I don't usually do sound work, I mostly develop apps so no sound at all so I have no idea how it all works and won't probably be helping much around that side of the app, image editor, code editor and UI design would probably be my main areas.

[technomancy]

So airstruck suggested the name ERÖS, which I really like. I've created a GitHub repo in an org (https://github.com/eros-love/eros) and an #eros channel on Freenode (#eros on OFTC was taken).

My next step is going to be improving the docs for Polywell since I think it makes sense to define the other tools in terms of polywell modes (I have Polywell modes for textual stuff like a simulated SSH client and a mail client, but I've also used it to create graphical interfaces like a map or a level editor, and it has worked really well for those.) Edit: I've added documentation for Polywell's API here: https://gitlab.com/technomancy/polywell ... /manual.md

We should survey the existing options for the sprite and music editors. Each of these should be usable as independent tools, but integrated into the buffer system inside the ERÖS codebase.

[WetDesertRock]

You might want to make polywell use relative requires, I had to do a find replace when putting it in my lib subfolder in my project.

[Beelz]

So, timing is everything... Maybe this could be integrated in some way, or at least be an inspiration in design?

[technomancy]

I'm starting to wonder if I wasn't a bit too ambitious in kicking off a big project like this. I have come to realize right now I really don't have the time to lead this effort or contribute very much without abandoning Bussard, my original game.

However, I did hear about another project which is also about making a Pico-8-like system in Love, though his vision is to remain much closer to the design of Pico-8: https://github.com/RamiLego4Game/LIKO-12

It's already come a long way in a short time, and I wonder if efforts wouldn't be better spent improving that instead.

Thoughts?

[RamiLego4Game]

However, I did hear about another project which is also about making a Pico-8-like system in Love, though his vision is to remain much closer to the design of Pico-8: https://github.com/RamiLego4Game/LIKO-12

It's already come a long way in a short time, and I wonder if efforts wouldn't be better spent improving that instead.?

It's pre-released here now: viewtopic.php?f=5&t=82913