Progress on supporting a subset of Markdown in my text-mode paginator, and how programming languages can use modules without explicitly importing them.
https://archive.org/details/akkartik-2min-2020-06-07
The algorithm you use to determine the types is interesting. Did you come up with that yourself? Or do you have any pointers to what inspired you?
I‘m also curious how you settled on Markdown parsing for the demo? I‘m strangely attracted to Markdown for a prototype as well.
I'm basically noodling on what a simpler world wide web looks like, where we only use browsers for reading and hyperlinking, not for web apps. The only reason there was a demand for sandboxed web apps historically was that native apps on PCs had so thoroughly polluted the well for users. But in a world where apps are always distributed with source and there's a culture of calling folks out for dark patterns, you don't need the web to run apps anymore.
My ideas here are a lot less well-formed than for the foundations of Mu, so I'm extremely open to suggestions. Markdown's just the first syntax I tried to avoid designing a 15th standard. Though I'm already seeing crap I'm never going to support, like this:
This is *emphasized
# text.* Or is it?
Things are simpler if I require headings to always start a new paragraph.
I came up with the algorithm myself, but it felt like a fairly straightforward multi-pass compiler design. The only minor issue was the chicken-and-egg problem of needing sizes to compute field offsets, and needing field offsets to compute sizes. I'm not well-versed with the theory of Algorithms so I can't cite good keywords here. But I think a lot of people would be able to come up with it after completing a grad course in compilers. Once the problem was framed.
Yeah, there are some weird edge cases in Markdown. I'm all for a simpler standard and would be happy to break backwards compatibility, getting rid of some of those weird edge cases. Complexity of implementation is particularly important for standards where we hope to see many implementations, but hardly ever considered.
We learn so much from implementing a thing, but we tend to only practice additive design, cramming more things into it over time. Maybe that is the nature of things. At some point more people feel that the old thing is now bloated and that opens the door for another, better designed, simpler thing to take over. Somewhat the story of Mu, I guess… ;)
I missed a week last week, due to being quite busy, and being stuck on a few things. Hopefully I can be forgiven the extra minute that this week's update contains. In the video I cover the LFO operators, and a new mode of FM synthesis.
This is sounding super nice, as ever. Did you fix the audio glitch from the previous video?
Also — is 2 LFOs always going to be the limit? It seems like the current UI for LFOs wouldn't really scale up to more. I'm curious to see if that's just a temporary situation, or if you're actually comfortable with this as (say) a creative constraint and plan to keep it that way.
Very cool progress! Your sound palette is really growing, very nice! Are you planning to make the graph editable either by live coding or visually editing it?
By way of partial explanation, my code dumps a GraphViz output so I can visualize the graph.
In the image you can see the LFO connected up to (so far) 3 generators and the bitcrush effect.
So to answer Ivan Reese question, there is no constraint with LFO's, except in how you wire them. You could add more LFO nodes, and hook them into units as you see fit. I suppose there is the limitation that, for example, the Oscillator pitch can only be modified by 2 (3 if you include the combination) LFO waves. I could certainly make the Oscillator take 'n' waves I guess - since I have the ability for pins that grow like arrays. I just thought that this was probably enough for now.
Maikel van de Lisdonk Scripting/Live coding is the goal. You can think of this as the visual result of your live code script. But I haven't discounted the option of editing the graph. You can see in one of my earlier videos that the canvas can be zoomed/panned - so I'm thinking about this for the future. This week I'm hoping to try some scripting.
Ivan Reese Regarding the audio glitch, it hasn't totally gone away, but I believe I know what it is; it comes down to memory allocations happening when they shouldn't. I will fix it soon.
That graphviz output is a nice feature. Is your graph currently already read from a file so that the needed node objects are created dynamically or is it being compiled beforehand?
GraphViz is really trivial to output; I wrote an old post about it here: https://chrismaughan.com/blog/coding/2019_07_01_graphviz/ Currently there is simple c-like API to the graph, intended to be driven by a script. Currently I just call it from C++, but I am adding a scheme layer to script it at the moment. So creating it from a file will probably be more like running a script from a file; but it wouldn't be hard to do a file format too.
(synth_def 'S1'
(node :instrument 'Instrument')
(node :pan 'Stereo')
(node :delay 'Delay')
(node :reverb 'Reverb')
(node :phaser 'Phaser')
(node :master 'Master')
(node :analyser 'Analyser')
(node :mixer 'DownMix')
(node :bitcrush 'Bitcrush')
(node :fm_osc 'Modulator')
(node :fm_osc 'Carrier')
(node :fm_osc 'Modulator')
(node :fm_osc 'Carrier')
(node :fm_osc 'Modulator')
(node :fm_osc 'Carrier')
(control 'Instrument' 'Modulator')
(control 'Instrument' 'Modulator')
(control 'Instrument' 'Carrier')
(control 'Instrument' 'Modulator')
(control 'Instrument' 'Carrier')
(control 'Instrument' 'Carrier')
(flow 'Stereo' 'Phaser')
(flow 'Delay' 'Reverb')
(flow 'Reverb' 'Master')
(flow 'Phaser' 'Delay')
(flow 'Master' 'Analyser')
(flow 'DownMix' 'Bitcrush')
(flow 'Bitcrush' 'Stereo')
)
Oh, and I actually dump a scheme-like data structure in the debugger for how the graph looks.. There it is ^
Let's keep videos to ~2 minutes, even if you miss/skip a week. My next update will likely be 2 months after the last (it's busy season in the garden), but it will still just be a ~2 minute video.
Two paragraph update: I released instadeq beta last wednesday, I've worked a lot the last 3 weeks but since it's polishing, bug fixing and making it usable to end users I didn't know what to show, I tried doing some "speed runs" but they were all over 2 minutes so I scrapped that idea.
I get the feeling that now I "sold to the mainstream" from this community's perspective.
i don't think you have sold to the mainstream. Instadeq is quite unlike most of the other projects. Why do you have this opinion? I find most of the people on this group to be so busy building their own inventions they don't have but a few minutes to devote to studying the competition.
I haven't seen much discussion about "crossing the chasm" from prototype to production/adoption and viable business models as I've seen discussions about the really early stages of development. That gives me the idea that many are interested mostly in the ideas and expect "if I build it they will come" to work for them. Beads is an outlier as I can picture it being used for "real stuff" in the short term.
Edward de Jong - Two comments, firstly; I have long lists of links to live coding tools and projects, and I have played with many of them. So from my POV, I have studied the 'competition' extensively. Secondly, I don't really think about 'competition' in that sense. What I'm building is something that I want to use, which fills the holes I perceive in the other tools. As Mariano Guerra says, I hope that if I build it they will come, but I don't have financial gain in mind; just the possibility that people might help build my passion project....
It might be an interesting poll to know who is building tools for business/profit reasons vs for fun/interest. I suspect on this group at least the balance is more firmly in the second category.
there's a third case that is not necessarily for business/profit but close, which is to democratize/simplify programming, but to achieve that you must achieve almost the same objectives as the business/profit group but without the benefit of being able to sustain its development
that means it's more ambitious but even harder, I would love to be able to give away instadeq for free, but I have yet to find a way to do that and sustain myself even with a fraction of the income I could be getting working for any software company
Chris Maughan — We covered that (sort of) in the 2020 Community Survey. There have also been some polls about this here in the past, but AFAICT they're now cloaked behind the slack history fog.
Mariano Guerra — futurists gotta eat too! Cheers on the beta release!
It might earn a few Hey!! objections if I said so out loud, but I think this sort of a "two [small] paragraph update" was a fine substitute for a video.