itch.io

Thanks for more info!

So I assume there is some JavaScript error on your Chromebook that prevents the page itself from functioning correctly. Unfortunately, without any knowledge what that problem is I wouldn’t be able to address it. Maybe somebody else will face it as well and will be able to poke deeper.

Your Linux setup seems fine from that description. It would be nice to see the entire error log though, could you show me what it prints from the top? From what you’ve already shown, it’s clear that the Godot runtime is operational, but the synthesizer library is not loaded for some reason. That’s very strange, and the only thing I can think of immediately is that it’s some permission issues.

Make sure that the .so file that comes with the Linux version is accessible by the same user who runs the Bosca executable. A library file like that normally doesn’t need an execution permission, but maybe it does in your case? Worth checking this as well. The ZIP already should have correct permissions otherwise (sans the user, of course), but if you unzip it on one machine and then copy to another these permissions can get lost in the process.

Hey, that’s unfortunate! What Linux distribution do you have, and what is your hardware? If you can capture the command line output from the beginning that would also help. It seems like the shared library is not loading on your device for some reason.

Regarding Chrome OS, is the whole landing page showing up blank or does it turn blank after you try to load the application? I ask because you should see at least the landing page itself, since it’s just a regular web page, and if it breaks at that point, this is not about the application itself. Could you open the devtools and see if there are any messages there?

Edit: Also you mention that the web version doesn’t work on Chrome OS, but what about Linux? Have you tried it on your Linux machine, in either Chrome or Firefox?

Self-hosting is a way of providing a web resource by hosting it on the server that you directly control, rather than using a service that hosts something for you and lets you control it via some high level tools like an admin or control panel.

When I talk about self-hosting I mean a situation where a developer hosts a web project of theirs on their own server or a server that they directly control, and not by uploading and embedding it on itch.

What got you so confused is my mention of the fact that I also provide the source files of the web version, so people who desire, for whatever reason, to host a copy of the project themselves, can do so. This is unrelated to my question, but I brought it up because you decided to make an argument about a situation where the project is not downloadable from itch. I merely pointed out that this is not the case for me, and that this is not a part of the premise for my proposal.

I provide source files because it’s an open source project. People are free to do with it as they please. So in good faith I provide as much as I can, because different users might have different needs. Which is, again, beside the point of this proposal and was but a side remark that I’ve added to highlight that the project is very much downloadable in my case, and that I use itch for its primary purpose.

This is not a blocker to me, and if leafo and team decide against this, or even completely ignore this suggestion, it wouldn’t really bother me. I just thought it’d be good to let the users know that the project is available on web in a way that is as noticeable as other related projects. It sucks to not be discoverable when great efforts have been put to make this version happen. But it is what it is, and I’d be fine with either resolution. Nothing hangs in balance for me. It’s just an idea.

I find your comparison inappropriate and pointless. There are no technical limitations for uploading any executable to itch and labeling them appropriately between the 4 supported platforms. If someone chooses not to do it, then, well, it’s up to them. Hosting web applications on 3rd party services like itch, however, is not always possible. While itch is extremely accommodating, it has its own things to consider. And as a developer I have to consider that if part of my users may have inadequate experience, I should make sure that they don’t.

I could upload the project to be hosted by itch in whatever form it can be, but that means I have to support this second web version of the app, in an environment that I do not control and cannot apply every fix possible if needed. This is undesirable, and it increases burden on me, as a sole developer maintaining a rather popular open source project. But again, I don’t demand or request itch to change anything about their support for web-based projects. And it’s not critical to me that they even consider my suggestion.

I just think it’s a good idea to help developers and users connect better. Your views seem to be rather conservative in that regard. So you try to convince me that I need to do something, that I’m approaching this incorrectly, that it’s mine and mine alone problem and my point of view is insignificant. You wave at the other comment here that mentions that they don’t want to go outside of itch’s ecosystem as if that should discourage me. You demand someone enlighten you why this should be such a brilliant idea.

What’s with all the gatekeeping? You’re making such a big deal out of a tiny suggestion, creating a hostile environment where the person proposing must prove something to you. I’m beginning to regret to even trying to propose anything. But maybe that is exactly what you want people to feel.

That’s fine. If this suggestion is implemented, there should be a clear indication if the project is available via a third party and not directly on itch. So you can avoid such projects if they are not your cup of tea.

And there can be extra guardrails too, like your project must be otherwise present on the platform. So itch doesn’t turn into an ad board for 3rd party services. Though I think it’s a bit premature to worry about that. And, besides, that can already take place regardless of this suggestion, as you are not required to upload any files for your project.

That makes little sense.

Key words are “don’t need to” and “can”. Hope it helps.

So let me get this straight

Quite frankly and with all due respect, I’m not asking for an advice on how to best distribute my projects. I’m explaining the circumstances and the problem with discoverability. If you do not believe it’s a real problem and think that my suggestion is unreasonable, just say so and let’s stop there.

Is this a translation issue?

I don’t like how this conversation is unfolding. And I’m sure you’re not trying to be rude on purpose, but the way you opened your initial reply and continue to engage with me is very unpleasant and hard to take in any way other than condescending.

You are perfectly clear. But you also make tangential and lengthy arguments which have little to do with the suggestion, like your opening point about projects not being available for download having no place on itch. And you also keep missing the point about source files being provided for download for those who want them — which has been just a side note, which I now regret making because it seems to have really confused you. And you keep trying to catch me on some technicality, posting, as if it’s some kind of proof, links to Godot games available on web or questioning my rationale for distributing the project the way I do.

To which end you do this I don’t know. I assume you just don’t see value in the idea, and that’s fine. You’re entitled to your opinion. The added scrutiny, insistence, and argumentative attitude is unnecessary. So let’s leave it at that, and have a nice day.

That’s absolutely fair! To be honest, I don’t think most people have a similar setup where they actively opt into stuff, but it’s still a valid approach.

If my suggestion is implemented in any way, I’d expect itch to clearly label projects which are available in a browser but hosted externally to keep the users informed. That would be essential in my opinion, and should help you avoid them just as well.

Thank you for your POV. Could you explain, why would you consider opening a project hosted on another domain a limitation specifically?

I appreciate that this is just your opinion, but you started your reply by arguing with a point that nobody made. You assumed something that was never stated and wasn’t the point of the suggestion.

Back to the discussion, there seems to be a misunderstanding about the context for my suggestion. The project is already hosted and available to everyone who wants to use it in a browser. Just not on itch. But you don’t need to download it and host it yourself, locally or otherwise. I simply mention that you can also download the sources for self-hosting, if you want to. Alongside desktop versions. I’m making a point that the project is fully available on itch as you expect, to address your assumption that the project is not downloadable/available directly.

Still, the web version itself cannot be hosted directly on itch. There are specific issues and there is a general problem with user experience. Specific issues boil down to Safari being picky about certain security HTTP headers and itch is configured in a way that doesn’t make Safari happy. Safari wants more strict headers than all other browsers, but that makes it impossible to do certain things. For example, integrate ads to your web projects. Itch is specifically configured in a more relaxed way, allowing for such features, and it works in most browsers. To clarify, I don’t need ads, it’s just and example of the rationale behind server configuration considerations.

Yes, Godot projects run fine on web, and so does mine. But Safari makes it problematic, and in my specific case I cannot use a workaround introduced in a recent version of the engine.

So, again, the case here is with a project that has web as one of its platforms. The project is available in the browser, but not directly on itch, for technical reasons. Still, users might be interested in it and the fact that it runs in a browser, even if you cannot do it directly on itch.

Who said anything about the project not being downloadable on itch? It is downloadable, for every desktop platform, and even the web version is available for download (for self-hosting), if you so choose. But the web version requires a server configuration not possible on itch (and probably for a good reason), and there are also other usability concerns with running it embedded.

This cannot be solved by a demo, as it’s not about features. And as I mentioned, the description already points users to the web version, if that’s interesting to them. The issue is that the project is not discoverable if the user looks for this type of project with a browser support.

Having an explicit option for browser-compatible versions which are hosted elsewhere can be used to gracefully handle user concerns, actually. Itch can have an explicit message that the project is hosted by a third party and even link some FAQ that explains the risks. Ultimately, it wouldn’t be any different from a link in a description, just with a benefit of actually being discoverable by users.

If that’s still suspicious to you, that’s fine. I just don’t see this as an argument against helping developers and users looking for browser apps and games to connect.

Hey!

As far as I can tell, the only way for your project to be recognized as browser-compatible is to use the feature where you upload it directly to itch.io. I have a case where I cannot do that. Mainly because I need a custom web server configuration and I don’t expect itch.io to support such situations, but also because I want a carefully crafted landing experience for people who chose to use the web version of my project. So this is fine!

This means, however, that my project is missing the shiny “Run in browser” tag across the platform, and cannot be found using related filters. And while I mention and link the web version, this is hardly the most important feature of the project, so it is only described in the middle of the project summary. Nowhere near where the supported platforms are listed on the page.

So my proposal here is to provide a way to indicate web support with an external link, which would opt the project into the system to be recognized and discoverable as a “run in browser” project. Now, I understand that you may have concerns about redirecting people to 3rd party resources, and if that’s a strong argument against this idea, I appreciate that. Still, I’d love to be able to tell people that they can use the project from their browser on the same level as other projects do, even if it is not hosted by itch itself.

On a sidenote, while looking for an answer I spotted this blog post which suggests injecting an iframe into the uploaded HTML file to sneakily use your self-hosted version. I’m not entirely sure if this is something that you openly support as a solution in this case, is it? If security is a concern, this seems equally problematic in my opinion. At least in terms of the phishing angle. In any case, this would probably not be a suitable replacement for me, because it doesn’t yield the best user experience.

Thanks!

EDIT: Just want to clarify that by “self-hosted” I refer to projects hosted externally, in relation to itch. I don’t refer to projects which are not hosted anywhere at all, which you need to download and host yourself or run locally in a browser. So assume that the project is already available, but for technical reasons cannot be embedded on itch and you have to navigate elsewhere to access it, if you want the browser version.

And in my specific case, the project is also available on desktop platforms. So the itch page is justified and is used appropriately. The web version is only one of the options.

Hey, just wanted to let you know that your report reached the engine team, and the case with disabled XDG portals should be properly handled by a future version of Godot:

https://github.com/godotengine/godot/pull/101812

For Bosca Ceoil I’d still need to do some work to properly support it, when it’s ready, but that shouldn’t be hard.

Thanks again!

I appreciate the details and you sorting it out on your end! I still logged in a report based on your comment to GitHub so it can be referenced and perhaps addressed at some point. I also noticed that some XDG backends don’t support file pickers, so perhaps there are affected users who’ve never even disabled the service explicitly.

As for your investigation in the codebase, yes, as I noted disabling the native flag on the FileDialog node is possible as a fallback, however this particular error is not reported by the engine to the script. popup_*() methods don’t return error codes or anything at all. So the only way to detect any problem would be to do it by some secondary tells.

So far I’m thinking about adding an app setting to disable native dialogs as a solution. But I won’t rush for it for now.

Thanks for your report and efforts, and hope you don’t have any more annoyances like that using Bosca :)

Hey! Bosca already uses Godot’s FileDialog, the last log message in your post is a native error in the engine. We use the native version of the file dialog so you have all expected features that your system provides.

I’m not a Linux user, so I don’t understand what you mean by “masked out the XDG portals”. Could you explain it, so I can think of a workaround, if one is possible in Godot?

Edit: I assume you meant using a non-native version of Godot’s FileDialog as a fallback. That could work, though I’m not sure I can detect the failure from scripting to react to it in any way. I think Godot should do it automatically by checking if portals are enabled to begin with (it has infrastructure for such a check too).

Could you explain to me why would someone be in a situation where these portals, which as far as I can appreciate are a security feature to safely work with sandboxing, are disabled? How common would that be?

Hey! In terms of musical timings the note length is fixed at quarter notes (1/4th of the beat). There is currently no way to change that (the setting that allows you to adjust the size of a bar is, unfortunately, purely visual), and I cannot change that until the next major release because it would break compatibility.

If you want effectively shorter notes you can use higher BPM for now.

No worries!

Hey there! MIDI is not a save format, it’s an export format. While Bosca tries its best to convert to and from MIDI, it’s impossible to do this flawlessly as its capabilities are different from Bosca’s. Generally export to MIDI should result in a valid MIDI file. Import from MIDI is available, but it’s far from perfect and not every MIDI file can be reasonably imported into the app because.

You should use Bosca’s own format for saving your work, and use export formats when you want to take your music out of Bosca somewhere else.

Sorry, this is a minor update, so it cannot introduce any breaking changes. Original Bosca Ceoil and current version of Bosca Ceoil Blue do not support more than 16 instruments, so that has to stay for now. I’ll revisit this limitation in the next major update.

No, that’s not normal. There is nothing unique about the arrangement view that would make the music lag. So it’s likely that the whole app is having performance issues on your device in the arrangement view. Can you tell me more about your hardware? Your CPU, GPU, RAM? Could you also check in the task manager, or your system’s alternative for that, if Bosca is stressing your system too much?

Hey! The new update is pretty much ready and the first beta will be out early next year. But for now it’s a holiday break. Do you have some suggestions, though, for what you want to see?

All shortcuts are listed in the app itself, in the help section.

Ah, don’t worry about it! It’s a bit of a confusing feature to begin with :)

Hey! It allows you to record different filter and volume values for the instrument that the pattern uses across the duration of that pattern. It’s explained in more detail in the “Tips and Tricks” guide in the Help section!

Hey there! While Bosca 3.1 is still in development, I’ve now completed the web version support, and you can give it a try here:

• https://humnom.net/apps/boscaceoil/beta/

Note that this is not the final version of Bosca Ceoil Blue 3.1, and there may be bugs, inconsistencies, etc. But if you can give it a go and let me know how it works for you, that’d be appreciated!

I had someone test it with a Chromebook, and it seems to work fine as a web app.

Hey! I’m working on the 3.1 update right now, and as a part of it I plan to release the web version. A version for Android will come at a later date.

Hmm, there shouldn’t be any difference whatsoever whether you start the .exe from the File Explorer or from a terminal. Can it be that it’s your antivirus/antimalware software blocking it, perhaps? Not sure what else to suggest here, because that’s a pretty unusual circumstance.

If there aren’t any errors when running from the command line, we can only guess about the source of the issue. I guess you can try making a .bat file in the same directory to execute the same command line operation with just a click, so it’s less cumbersome.

Sorry if I can’t be of any more help, but I’m really confused by your findings.

Hey there! No, old Bosca doesn’t affect the new version in any way. Are you familiar with the command line/terminal for your operating system? Could you open it from the folder where you unzipped to and run Bosca Ceoil Blue this way? This should show some errors if the problem is with the app.

Yes, I definitely have plans to release on Android :) It’s all just a matter of adapting the UI and input handling for small touch-sensitive screens. The synth itself works perfectly fine on Android already.

For iOS I just don’t have the hardware to develop on. I can kind of just build for macOS blindly, trusting the engine’s support, as it is just another desktop application, but I don’t think this will work well for iOS/iPadOS releases, unfortunately.

Yes, this is very useful, thank you!

I can’t promise a quick turnaround on this because this is a result of a design decision that I’ve made. For aesthetics reasons I wanted the app to have a vertical layout and fit on one screen as much as possible (so no scrollbars). Which unfortunately means a situation like your last screenshot is possible.

I do want to explore an alternative horizontal layout for it at some point, which I think will work for your case the best. Just not right now, as I’m switching my attention to another project for a bit. But I promise this will be sorted out eventually!

Hey there! I just released an update with a handful of hotkeys added for your convenience. They aren’t rebindable, but I hope they are sensible at least (for the keyboard especially). You can find them in the new settings menu!

Let me know, if you have more suggestions!

Hey, I just updated the app so it should work well on your screen. Tested it on my other 1080p laptop, and made it fit the screen and be properly scaled!

Let me know how it works for you <3

It exports to WAV!

But which text is too small for you? That’s not good, and I’d like to fix that.

Edit: It just so happens, I was working on an update for the last couple of days, and just released it. It introduces a GUI scale setting. Let me know if it helps with your issue!

https://yurisizov.itch.io/glasan-fx/devlog/825512/glasan-fx-gets-smaller-and-gets-shortcuts

That’s a fair point, I’ll see what I can do about it!

Thanks! You didn’t miss anything, don’t worry. There aren’t keyboard shortcuts just yet, but there of course should be. Adding some for the piano roll and the randomizer makes sense to me.

Please stop posting the same question over and over. As I’ve said, I’ll get back to you on GitHub once I have time. I appreciate your desire to help, but spamming is not helpful.

Sure, I’ll get back to you on GitHub.

That’s why I mentioned the IOManager class. That’s where the GUI is connected to the logic behind the export process. That’s where user interactions are handled, and then an exporter class handles the rest.

Exporters and importers are just classes coded in GDScript, which create either a string or a binary buffer according to the format specification, and write them to disk. You can find them in the io folder, and the GUI hooks are in the IOManager class.

Hey, thanks for the offer! The project is open source, so if you’d like to contribute just drop by the repo anytime and see if there is any bug that you’d like to fix:

https://github.com/YuriSizov/boscaceoil-blue

For features, please open an issue or a discussion first if you have some ideas, so we can arrive to the solution together before committing to anything.

Are you familiar with the command line/terminal on your system? Could you try running Bosca from it and let me know what the output is?

Hey, can you give me a bit more details? What operating system do you have? And what steps specifically do you attempt to take which don’t work? Would be very helpful if you could record a short clip on it too.

No, this is a hard limitation of this app. For the synthesizer that the app uses this handling more tracks in polyphony is not a problem, but this might not be the case for various external formats like MIDI. So for now I don’t have plans to allow for more tracks, 8 seems like a good middle ground for the target audience of Bosca.