I like the idea!
I am not too familiar with discourse, but I know it supports plug-in development. Maybe it would be possible to integrate this within the forum?
I like the idea!
I am not too familiar with discourse, but I know it supports plug-in development. Maybe it would be possible to integrate this within the forum?
Oh brilliant, Iâll take a look in to that - if itâs fairly straightforward, that might be a runner. I see this project as something that develops over time to suit the needs of the community so even if it starts out as a separate website, I might move it over to a discourse plugin eventually.
I think the solution is for more of us to make wildly awesome and popular Kosmo models until MG has no choice but to list us.
This is a great idea! Markdown all the way as I for one am hopeless at programming (whatâs JSON?)
JSON (Java Script Object Notation) - not as complicated as it sounds - is a way of describing data. For example a module might be described like:
{
"name": "MS20 Filter",
"hp": 8,
"maker": "Look Mum No Computer",
"description": "MS20 style filter inspired by the René Schmitz design",
"link": "https://store.lookmumnocomputer.com/collections/modules/products/1113-kosmo-2-0-performance-filter",
"image": "https://cdn.shopify.com/s/files/1/0253/6040/0430/products/1113_-_Pic1_300x300.jpg?v=1617289125",
"type": ["pcb+panel"],
"function": ["filter"]
}
This could then be used by the website to display a nice list of modules with links, images and filters - not unlike modular grid. The advantage of JSON over other formats is you can have arrays of values for modules that may have more than one function.
Maybe yaml? Itâs kind of between Json and markdown
All of these formats are best handled and generated by code via object serialization than a person. So really just use whatever you want to support in the backend. I have a preference with Jason since itâs very comparable across languages, but itâs not like using something else would be a big hurdle.
The site should have form inputs that map to a data model.
You can then manage things like required fields etc and update the db in the back end. Not sure if this can be done with simple GitHub hosting though. Never actually used it, I donât deploy stuff there!
I imagine their hosting to be a simple serving of html, js, and css. So anything backendy might require remote db solutions.
JSON it is then, for now - updates will be managed via pull requests, again for now. If it looks like it might be worthwhile doing something more sophisticated then Iâll cross that bridge when I come to it.
Yeah, no need to over engineer this. As long as it lintâs, it can sits.
A very rough v0.1.0 of Kosmodular Grid is here: https://www.kosmodulargrid.com
Using mock data for now but it should demonstrate the idea. I have a todo list the length of my arm for stuff that still needs to be done and Iâll probably create a brand new thread detailing how anyone can add modules and future plans.
Next job for me is to add the LMNC modules. Anyone who wants to see the code or take a look at the data format can look at the github: GitHub - boylejack/kosmodulargrid
Data is in the public/data directory
Widths should be in cm, not âHPâ.
You can add âstripboard layoutâ between âPCB+Panelâ and âschematicsâ, there are a tons of them.
And there are also some âPanel onlyâ for converting MFOS/BMC/etc⊠PCBs to Kosmo.
I added a PR fixing a typo in the page header. It says Komsodular in the tab name.
Iâm going to domain squat that and create a modular parody site
The filter values are driven by the data so as soon as some modules are added that are stripboard only, the filters should update to suit.
amazing!!! I really like the new module styles. if only all synth modules were just faces of kittens haha. this is Stella work! awesome.
Thanks! Excited to get everyoneâs cool modules up on the site now.
yes! do you need photos of the Kosmo Modules? front on?
That would be amazing!!! Yes please!
Iâll also be adding my modules once you release a guide how to. Looking forward!