|
giogadi posted:Hey y’all, I’m trying to build a web app that lets you play a virtual synthesizer, where you interact with the synth by turning knobs, moving sliders, manipulating a step sequencer, etc. I’m also interested in exploring new UX for manipulating sound. I like doing as much as possible with html+css, you can go really far nowadays with CSS3 and transitions. The canvas approach requires you to code everything basically from scratch, including font handling (which sucks rear end in canvases) and there is honestly not much that HTML+CSS can do that a canvas can't. In the end you will probably end up making a hybrid, with complicated controls implemented by a canvas.
|
#
?
Apr 10, 2019 16:01
|
|
|
|
| # ? Apr 27, 2024 15:04 |
|
|
prom candy posted:The Guardian just posted this article about their CSS situation and it applies pretty nicely to this discussion. Kinda long but well worth reading: https://www.theguardian.com/info/2019/apr/04/revisiting-the-rendering-tier I was curious about what font use this website and it checked. They seems to use this one: https://commercialtype.com/catalog/guardian_egyptian_text Guardian Egyptian I appreciate this, a newspaper that have his own font.
|
|
#
?
Apr 10, 2019 16:46
|
|
|
go play outside Skyler posted:I like doing as much as possible with html+css, you can go really far nowadays with CSS3 and transitions. The canvas approach requires you to code everything basically from scratch, including font handling (which sucks rear end in canvases) and there is honestly not much that HTML+CSS can do that a canvas can't. Thanks so much! Of course my prototype had no labels so I never even realized that fonts/text would be a huge chore. Time to dig into MDN’s html/css lessons
|
|
#
?
Apr 10, 2019 17:23
|
|
|
Another thing you might want to consider is SVG for knob components.
|
|
#
?
Apr 10, 2019 17:28
|
|
|
Not sure why but I can't resist this:gbut posted:Another thing you might want to consider is SVG for knob components. lol ur a knob component 
|
|
#
?
Apr 10, 2019 17:32
|
|
|
gbut posted:Another thing you might want to consider is SVG for knob components. Personally I dislike knob components as they are very hard to manipulate with a mouse or touch and unsuited completely for keyboard. Knobs are perfect for our fingers in the real world, but they don't translate very well in an application's UI. Sliders are a better fit, serve the same function and can be more flexible and precise than knobs could ever dream of being. Just my opinion.
|
|
#
?
Apr 10, 2019 17:37
|
|
|
Volguus posted:Personally I dislike knob components as they are very hard to manipulate with a mouse or touch and unsuited completely for keyboard. Knobs are perfect for our fingers in the real world, but they don't translate very well in an application's UI. Sliders are a better fit, serve the same function and can be more flexible and precise than knobs could ever dream of being. Just my opinion. Some DAW I used in a past life let you control knobs as a slider. Just click and dragged up or down, and the knob graphic rotated appropriately. I thought it worked fine.
|
|
#
?
Apr 10, 2019 17:55
|
|
|
skeumorphic design sucks more often than it doesn't suck
|
|
#
?
Apr 10, 2019 17:59
|
|
|
Volguus posted:Personally I dislike knob components as they are very hard to manipulate with a mouse or touch and unsuited completely for keyboard. Knobs are perfect for our fingers in the real world, but they don't translate very well in an application's UI. Sliders are a better fit, serve the same function and can be more flexible and precise than knobs could ever dream of being. Just my opinion. This is totally valid, I think sliders are a better interface for a mouse. I’m thinking about knobs because they are super common on hardware synthesizers, and it seems that a lot of music people enjoy having software synth UI look similar to hardware. The knob+slider idea above also seems like a good idea.
|
|
#
?
Apr 10, 2019 17:59
|
|
|
The Fool posted:Some DAW I used in a past life let you control knobs as a slider. Just click and dragged up or down, and the knob graphic rotated appropriately. I thought it worked fine. That was one of my main pet peeves with them: I drag up and down (or left and right) and you rotate. Ughh... Then again, maybe some people like them. They are certainly familiar to those in the professional audio business.
|
|
#
?
Apr 10, 2019 18:08
|
|
|
Volguus posted:That was one of my main pet peeves with them: I drag up and down (or left and right) and you rotate. Ughh... Then again, maybe some people like them. They are certainly familiar to those in the professional audio business. Yeah that’s very unintuitive. One of my goals for this project is to make the synth very easy to use for newbies, which might motivate straying from industry norms like knobs.
|
|
#
?
Apr 10, 2019 18:18
|
|
|
ESL here, so I used "knob" as a generic "synthesiser interface thingamajig" word, but yeah. Rotating knobs via mouse / trackpad suck and you should not do that skeumorphic crap. E: what I meant, if you are making a complicated interface component, SVG might be more flexible than HTML, but also easier to do than canvas.
|
|
#
?
Apr 10, 2019 18:45
|
|
|
Tei posted:I was curious about what font use this website and it checked. A lot of the bigger papers have their own font(s) in my experience.
|
|
#
?
Apr 10, 2019 19:04
|
|
|
You mean like Times New Roman?
|
|
#
?
Apr 10, 2019 19:19
|
|
|
giogadi posted:Yeah that’s very unintuitive. One of my goals for this project is to make the synth very easy to use for newbies, which might motivate straying from industry norms like knobs. If the interface is intended for newbies, then using familiar but bad-for-digital controls probably isn't worth it - newbies don't have anything to compare it to (so no/minimal design affordance gained), so no real point in sacrificing optimal digital interface patterns for cool-looking but annoying-to-use-with-a-mouse knobs and poo poo. Sliders and toggle switches and buttons are fine and good. At my job, we sometimes get users wanting horrible overly skeuomorphic visualizations like speedometer-style radial gauges with a little needle and everything. Usually because other products they use (with lovely UIs) have them. I had to explain that they are completely superfluous in a digital interface where we have no analog sensor readings that work by pushing around a physical needle, and if you don't have to accommodate a physical needle gauge, then you can just use a much more compact bar gauge or even just some color encoding to get the same point across without wasting all that space. And then no one seems to understand that trying to use a radial gauge with a relative range and relative performance thresholds (which is how most of our readings work) fucks with you because a given needle position is not always going to point to the same value, so you lose any sense of spatial context like you have with real radial gauges with a fixed range of values/thresholds. Ugh I hate them so much. No one has requested knobs, at least. PS: A few days back I had written up a huge response to a lot of the CSS-in-JS discussion and then it got eaten and I've yet to muster up the will to write it out again...
|
|
#
?
Apr 10, 2019 19:45
|
|
|
Doom Mathematic posted:You mean like Times New Roman? Yeah, that's the most sucessfully commercialised example. Gotham (GQ magazine) is another big one. It's maybe a bit less common for newspapers/magazines now as print media dies. But almost every [very] large established company has their own fonts, it's just relatively unusual for them to be available commercially (See also v large tech companies commissioning UI fonts)
|
|
#
?
Apr 10, 2019 20:34
|
|
|
The Fool posted:Some DAW I used in a past life let you control knobs as a slider. Just click and dragged up or down, and the knob graphic rotated appropriately. I thought it worked fine. I remember using one where you would hover over the knob and then use the mouse wheel which was cool but took me a while to figure out. Still better to just use a slider though.
|
|
#
?
Apr 11, 2019 11:31
|
|
|
Skeuomorphic design in digital instruments makes a bit more sense when those controls can be mapped to a physical controller with actual knobs and sliders. Probably my favorite digital instrument control to use with a mouse is an actual graphical representation of an envelope that can be manipulated by clicking and dragging different points. Very intuitive imo.
|
|
#
?
Apr 12, 2019 02:53
|
|
|
I cannot remember the name of that media player from the windows 3.1 days that looked like a stack of stereo components with little knobs you fiddled with. My googlin' is failing me now. I used to think it was so cool...especially when I got a SCSI CD-ROM drive that it would control.
|
|
#
?
Apr 12, 2019 16:00
|
|
|
Thermopyle posted:I cannot remember the name of that media player from the windows 3.1 days that looked like a stack of stereo components with little knobs you fiddled with. My googlin' is failing me now. Oh poo poo I remember that! Windows 3.1 also had an amazing skeumorphic telephone program that I really enjoyed. That poo poo was the future.
|
|
#
?
Apr 12, 2019 17:13
|
|
|
My VSCode has been randomly freezing for like a solid 5 seconds occasionally since the last update.
|
|
#
?
Apr 12, 2019 22:22
|
|
|
prom candy posted:I like the react-testing-library approach of only testing DOM output and not really bothering with unit tests for components. If you or your employer can spare the cash I thought TestingJavascript.com was a really good video series, it's pretty React-centric and done by the guy who created react-testing-library. Cool, definitely going to add some feature level tests using this. Seems like it’s high level enough you could even write the tests first, BDD style.
|
|
#
?
Apr 14, 2019 15:27
|
|
|
I need help because I clearly don't understand all the "magic" going on with React-Redux and the store. I have a 3rd-party component that has its own Provider, and while it worked at one point, after re-organizing my app it blows up with an error quote:Could not find "store" in either the context or props of "Connect(Provider)". Either wrap the root component in a <Provider>, or explicitly pass "store" as a prop to "Connect(Provider)". I don't really think what is effectively a grandchild component at this point should have direct access to the store, but I've tried passing in what it appears to need via mapStateToProps and even the slice of the store that it says it wants (the slice simplewebrtc of the full store). Finally I tried from the docs doing the ReactReduxContext.Consumer thing where I pass store in and now I just get quote:Could not find "store" in either the context or props of "Connect(class_1)". Either wrap the root component in a <Provider>, or explicitly pass "store" as a prop to "Connect(class_1)". Why isn't the store just propagating down? In the React Devtools I have the following hierarchy:  The highlighted piece is what gets replaced with the component that blows up if I branch a different way. Should I be concerned that VTCPage appears to have the Context but its subcomponents VTCSchedule and other peers do not? So far I don't have a really good way to debug what elements know about the store in either the React or Redux browser devtools.
|
|
#
?
Apr 15, 2019 02:40
|
|
|
Hed posted:I need help because I clearly don't understand all the "magic" going on with React-Redux and the store. The store doesn't "propagate" in Redux. The store is held in a Context. You can access it by using Connect() which provides that context to said connected components. When you use the Redux 'Provider' component around your App, it will create a context (unless you provide your own, which you don't really want to do), then it wrap the App in a Context.Provider (as seen in your image) which handles updating changes to the store. When you use Connect later inside, you wrap the connected component in a Context.Consumer. Without seeing any code, it's tough to tell, but perhaps your VTCPage added / is trying to add a second Provider component? You should only have one most likely.
|
|
#
?
Apr 15, 2019 03:24
|
|
|
Complete aside: I posted a while back about VSCode doing all sorts of nasty things (100% CPU, losing auto-complete, etc.) and I realized it started soon after updating it. Rolled back to the previous version and it's been chugging along happily for days.
|
|
#
?
Apr 15, 2019 17:55
|
|
|
Thanks Lumpy. I was able to get the React DOM to put that Context.Provider down in the grandchildren by doing connect so I understand that a bit better now. I still have the same issue; totally agreed that usually you have one Provider, however this 3rd party component has its own "Provider" thing, and it's very opaque to debug. One of my frustrations is that now I realize I got this same store violation error message back when I was moving the project to Redux (versus using the 3rd party component's redux bindings) because I didn't have my applyMiddleware(thunk) call in my createStore function call. So now I have two possible hypotheses, and it's very hard to troubleshoot either one. I'm probably missing a lot but this ecosystem seems a lot harder for me to "get" the tooling reasoned about.
|
|
#
?
Apr 16, 2019 01:52
|
|
|
Lumpy posted:Complete aside: I posted a while back about VSCode doing all sorts of nasty things (100% CPU, losing auto-complete, etc.) and I realized it started soon after updating it. Rolled back to the previous version and it's been chugging along happily for days. Autocomplete seems to be where it chugs for me too, yeah.
|
|
#
?
Apr 16, 2019 05:58
|
|
|
In React how bad is it to load all your data into the initial state? Here's my setup: Within App is a component called Contest which will render once for every instance of a "contest" entry in the database (so it could be many many times). All the contest data gets fetched by App but the Contest components get rendered lazily on scroll. Each contest relies on the user data passed into it from App. The way I see it I have two options for loading the user data: either make an AJAX call from every single Contest to fetch only the user data for that contest, or load all the user data into the initial state of App and pass it down. Or is there a third option?
|
|
#
?
Apr 16, 2019 16:06
|
|
|
Pull the next page or two worth of items in the background when the user scrolls down far enough to trigger the renderer?
|
|
#
?
Apr 16, 2019 16:17
|
|
|
Spatulater bro! posted:In React how bad is it to load all your data into the initial state? _If_ you can get away with loading all the data imo do it; it'll make your life a helluva lot easier. And if there are an obscene number of contest records, then can you get the data in paginated blocks (edit, and then do what Clark Nova says)?
|
|
#
?
Apr 16, 2019 16:32
|
|
|
RobertKerans posted:_If_ you can get away with loading all the data You mean from a performance perspective? That's my main concern. And I'm not sure how to measure the effect the size of the initial state has on load time.
|
|
#
?
Apr 16, 2019 16:49
|
|
|
Spatulater bro! posted:You mean from a performance perspective? That's my main concern. And I'm not sure how to measure the effect the size of the initial state has on load time. Yea, from a performance perspective. Make a judgement call based on literally how long the request takes for a user with chunky data, and just see whether you're happy with that or not? It depends on how much data there is for each record: if there isn't much then grabbing it all at once maybe won't be too costly. And you could always just make a request for a subset of the data (at the most minimal, just the collection of IDs for each record + I guess some descriptive field). Then that allows you to render UI. Then you can request more detailed individual records when a user selects one of them (obviously this depends on how your app works) RobertKerans fucked around with this message at 17:14 on Apr 16, 2019 |
|
#
?
Apr 16, 2019 17:11
|
|
|
Only if GraphQL or similar API that allows you to define the response scope. If you don't have control over the API output, I'm not sure if you could pull something like that easily with a large set of large records. Chunking would be better in that case.
|
|
#
?
Apr 16, 2019 18:34
|
|
|
gbut posted:Only if GraphQL or similar API that allows you to define the response scope. If you don't have control over the API output, I'm not sure if you could pull something like that easily with a large set of large records. Chunking would be better in that case. Ah that is true, my head's been stuck in GQL stuff for the last few months and I kinda forgot it wasn't that easy. Pagination is normally pretty doable. Need to more of an overview of the whole thing though (what counts as a lot of records, how much data is coming through per record, etc) RobertKerans fucked around with this message at 18:49 on Apr 16, 2019 |
|
#
?
Apr 16, 2019 18:45
|
|
|
I’m a React newbie, and I’m now learning about the hellworld that is drag-and-drop. I’m building a relatively simple app that just has a few lists that occasionally need to be rearranged. Every DND library out there either seems like a huge overkill or isn’t actively maintained. I guess I don’t really need drag-and-drop, but if I can just have one UI button (a drag handle) instead of two (up/down buttons) then that seems like a nicer design.
|
|
#
?
Apr 17, 2019 20:47
|
|
|
tankadillo posted:I’m a React newbie, and I’m now learning about the hellworld that is drag-and-drop. I’m building a relatively simple app that just has a few lists that occasionally need to be rearranged. Every DND library out there either seems like a huge overkill or isn’t actively maintained. http://react-dnd.github.io/react-dnd/about Also, before you go with Drag & Drop, use it on a phone, and with a keyboard only. Decide if it's worth it only after doing those two things.
|
|
#
?
Apr 17, 2019 21:34
|
|
|
Lumpy posted:http://react-dnd.github.io/react-dnd/about Yeah, I think this will probably go on the backburner for now. Getting a solid non-D&D UI is probably a bigger priority for this project. I have another general React question. In my app, I have a JS module that handles all of the data computation separately from my JSX components. I end up basically storing all of its data into state variables though (or at least references to its objects), and keeping those in sync with the “master” copy. I find myself sometimes updating the state first and then copying data to the master version, and sometimes updating the master version and then using that to set the state. Is there a general guideline for the “best” way of handling this pattern? My app is still pretty basic and doesn’t really transmit data over a network or anything, but I’m trying to set it up as consistently as I can.
|
|
#
?
Apr 18, 2019 00:14
|
|
|
tankadillo posted:Yeah, I think this will probably go on the backburner for now. Getting a solid non-D&D UI is probably a bigger priority for this project. You should only have one source of truth for data in your application, and it shouldn't be your component state.
|
|
#
?
Apr 18, 2019 01:32
|
|
|
Seconding this. Works well, once you learn the somewhat-messy API. Let me know if you have trouble setting it up.
|
|
#
?
Apr 18, 2019 02:01
|
|
|
|
| # ? Apr 27, 2024 15:04 |
|
|
tankadillo posted:Yeah, I think this will probably go on the backburner for now. Getting a solid non-D&D UI is probably a bigger priority for this project. Why are you doing it this way? Generally you don't want to be syncing data like that unless you actually want the data to be able to become unsynced (like copying data into state for a form knowing that the user will be editing it)
|
|
#
?
Apr 18, 2019 05:03
|
|