Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user LoWLiFe ! (Registered 2020-09-17) You are not logged in 
CSDb User Forums


Forums > C64 Composing > SID Factory II
2020-06-05 15:41
JCH

Registered: Aug 2008
Posts: 182
SID Factory II

Laxity and I have decided to go BETA with SID Factory II to let all curious SID composers also have a go at this cross-platform SID editor.

We have a Facebook group that you are welcome to join. There's also a nifty user manual there. If you're not on Facebook, this thread should serve as another place where we can share questions, ideas, music, bugs, new builds, additional files, etc.

Please note that although SID Factory II is quite stable and more than capable of editing SID tunes at this point, it is still missing a few essential things such as e.g. sub tunes. We have a solid ToDo and will post new builds here as they become available.

The first official BETA build: SIDFactoryII_20200604.zip
2020-06-05 15:52
Groepaz

Registered: Dec 2001
Posts: 9532
Since you mention cross platform... can you link the source too? Ever since walt (i think) mentioned it, i was waiting for it so i can perhaps hack support for my sample player things into it (the current workflow with converting and mod editing is terrible).
2020-06-05 16:02
JCH

Registered: Aug 2008
Posts: 182
The source code is not shared at this point. It's Laxity's baby for now. =)

What is meant by cross-platform is that he coded it with cross-platform compatibility in mind. It should be possible to compile it later for Mac, for instance.

But for now, it's for Windows.
2020-06-05 16:29
Groepaz

Registered: Dec 2001
Posts: 9532
ok, too bad
2020-06-05 17:18
tlr

Registered: Sep 2003
Posts: 1391
Cool! Is this modular like SID Factory 0.5 (alpha 1) so you can add custom players?
2020-06-05 20:25
JCH

Registered: Aug 2008
Posts: 182
Yes.
2020-06-05 21:16
ZeSmasher

Registered: Feb 2003
Posts: 439
I can't play any instrument other than a whistle, but thanks for the release!
2020-06-06 14:38
JCH

Registered: Aug 2008
Posts: 182
The user manual for SID Factory II build 20200604 is now available as a PDF file.
2020-06-06 21:47
Digger

Registered: Mar 2005
Posts: 365
Sounds fantastic. Wondering if it would be possible to compile to a web version.
2020-06-06 23:10
JCH

Registered: Aug 2008
Posts: 182
No, but a Mac version is coming.
2020-06-07 12:04
JCH

Registered: Aug 2008
Posts: 182
About the source being shared later, Laxity just wrote this in our Facebook group:

Quoting Laxity
I think I have to release the source code as per the license to use ReSID. I will do so, when the internal data formats have been solidified, so that anyone wanting to modify the editor has a fair chance to retain compatibility.
2020-06-07 12:11
Groepaz

Registered: Dec 2001
Posts: 9532
OH oH. Not trying to be an ass but - in this case you can not release a binary (unless you release the source) either. Please don't delay this for too long :)
2020-06-07 13:46
JCH

Registered: Aug 2008
Posts: 182
The archive in the original post has now been updated to include the PDF user manual, plus the overlay has been fixed to work on desktop resolutions at least 1920 pixels wide.
2020-06-07 20:41
Laxity

Registered: Aug 2005
Posts: 450
Groepaz, I believe the source code for the editor must not be released in the same way as the binary, but accessible upon request without consideration. So if you insist that you WANT it, I have to give it to you. I do however not have to make it available for download.
2020-06-07 22:23
Groepaz

Registered: Dec 2001
Posts: 9532
Yes Yes, sure. You can also demand me sending a written request and a small fee (please don't) (But technically, you must always include instructions on how to do this, and the GPL, see the first paragraph here).

As said, please don't delay it forever, obviously i also prefer the source in a "clean" state :)
2020-06-08 00:06
Laxity

Registered: Aug 2005
Posts: 450
I'll make it as clean as can, especially for you! Just let me know when you really need to have it!
2020-06-08 13:02
Digger

Registered: Mar 2005
Posts: 365
btw. These driver test tunes are awesome, shows Laxity's versatility as a composer! <3
2020-06-08 13:07
Groepaz

Registered: Dec 2001
Posts: 9532
If only you had released 4 weeks ago when my vacation time started =P
2020-06-08 15:03
JCH

Registered: Aug 2008
Posts: 182
Yes, his demo tunes are truly amazing.
2020-06-10 23:40
JCH

Registered: Aug 2008
Posts: 182
The second BETA build is now available. It also contains an updated version of the user manual.

List of changes in this build:

- Ctrl+P toggles follow-play on or off
- Keypad + and Keypad - can now be used to select the instrument
- Ctrl+Keypad + and Ctrl+Keypad - can now be used to select the command
- After having played a note with Shift held down, Ctrl+Space in tables will repeat it with the selected command also applied
- Ctrl+I in a sequence now inserts the currently selected instrument
- Ctrl+O in a sequence now inserts the currently selected command
- You can now also use Enter (or left-click) on a row in bookmarks to jump to that spot in the song
- You can now also use Ctrl+Enter (or double-click) on a row in bookmarks to jump to that spot in the song and play from it
- Reversed the direction of the CPU usage graph in the Ctrl+D debug screen (also called the Flight Recorder)
- The current song name is now shown in the windows caption
- SF2 files in File Explorer can now be associated with the editor

Download it here: SIDFactoryII_Win32_20200610.zip
2020-07-03 15:16
JCH

Registered: Aug 2008
Posts: 182
I've written a command-line tool for SID Factory II that can convert 4-channel MOD files to SF2 source tunes.

Download it here: SF2Converter_20200703.zip

Read the text file in the archive for more information.
2020-07-03 16:52
GH

Registered: Sep 2014
Posts: 73
Ah that's a great tool ineed.
I personally would prefer a XM2SFII This would be the gamechanger imo
Just 3 tracks, Instrument number,note and duration or maybe === note.
This because the mod "reach" c4-b6 can be very tedious at times to get your midi in.
At the moment I convert from MID2XM -) XM2GT2

But if you have old mods laying around it's perfect :D
2020-07-04 13:02
Laxity

Registered: Aug 2005
Posts: 450
MIDI2SF2, would also be nice... Jens? Haha. ;)
2020-07-04 13:13
JCH

Registered: Aug 2008
Posts: 182
Give me 5 minutes
2020-07-04 14:02
GH

Registered: Sep 2014
Posts: 73
:D

@JCH: And while you at it make SidFactoryII
DAW version as well ;)

Nah, I red you were looking into GT2SF... if this succeeds
my first question is answered and my workflow makes even more sense :D
2020-07-05 09:33
Shogoon

Registered: Jul 2007
Posts: 8
Quote: MIDI2SF2, would also be nice... Jens? Haha. ;)

Omg, it would be golden feature:)
2020-07-06 09:56
Digger

Registered: Mar 2005
Posts: 365
Second what Shogoon said! Perhaps opensourcing the converter would be a good idea too?
2020-07-06 11:54
Jammer

Registered: Nov 2002
Posts: 967
Tried it finally. My first impression is kinda cumbersome handling :D But maybe it's a matter of getting into it.
2020-07-06 12:22
JCH

Registered: Aug 2008
Posts: 182
YMMV of course. I always thought GT2 had a crazy way of handling the space bar. ;)
2020-07-06 14:57
Groepaz

Registered: Dec 2001
Posts: 9532
Quote:
Perhaps opensourcing the converter would be a good idea too?

That reminds me to say: including the GPL and the notice on where to get the source is NOT optional.
2020-07-12 21:53
Rayne
Account closed

Registered: Jan 2002
Posts: 30
If the source won't be shared yet, can you also add a Linux binary?
2020-07-17 09:32
JCH

Registered: Aug 2008
Posts: 182
Laxity plans to release the source code later (the use of ReSID requires us to do so) after cleaning up some things in it. We don’t have an ETA yet, though.

In other news, a new build of SID Factory II has been released.

The main feature of this build is descriptions for commands and instruments.



Visit my blog post for downloads along with a list of changes.
2020-07-17 10:44
tlr

Registered: Sep 2003
Posts: 1391
Quote: If the source won't be shared yet, can you also add a Linux binary?

+1

would be nice to try this.
2020-07-17 13:14
Groepaz

Registered: Dec 2001
Posts: 9532
Quote:
Laxity plans to release the source code later (the use of ReSID requires us to do so)

That's not quite correct. You are required to send over the source to anyone who asks. You are also required to provide the source that enables the one who asks to build the exact same binaries that you released. You are _also_ required to put a GPL notice in your binary releases, and a notice that explains how to get the source. And it would be really nice if you'd not violate the GPL requirements. *sigh*

I will post a linux binary once the source is there for that matter :)
2020-08-11 12:41
AMB

Registered: Nov 2005
Posts: 14
Would you be so kind to post the MacOS version here when there is one ready? Thank you! :)
2020-08-11 13:25
JCH

Registered: Aug 2008
Posts: 182
Sure. The latest version of SF2 for both Windows and Mac will always be available in the top of this page.
2020-08-11 14:51
freℚvibez

Registered: Nov 2002
Posts: 24
Any chance for a Linux version? :)
(would love a static binary or Debian package)

How about releasing it under a permissive license?
2020-08-11 21:07
Groepaz

Registered: Dec 2001
Posts: 9532
It _is_ GPL, they just choose to ignore that fact apparently.
2020-08-11 21:13
Compyx

Registered: Jan 2005
Posts: 576
Still not adhering to the GPL? Are you guys afraid to publish your code? Is it that shitty?
2020-08-11 21:52
Jammer

Registered: Nov 2002
Posts: 967
I bet they're not quite fond of any 3rd party branches at this point of development? ;)
2020-08-11 22:05
cadaver

Registered: Feb 2002
Posts: 1135
But it's not like any 3rd party forks would need to be supported, or even need to avoid breaking changes in the main branch. The "you break it, you get to keep both pieces" part is already covered by the GPL license itself.
2020-08-12 00:01
Krill

Registered: Apr 2002
Posts: 1521
Quoting JCH
Laxity plans to release the source code later (the use of ReSID requires us to do so) after cleaning up some things in it. We don’t have an ETA yet, though.
Ugh, reading that kind of nonsense* would normally set me off quite a bit. Reading this on a renowned C-64 forum, though, by renowned C-64 musicians using a renowned SID emulator... not sure. Jury out until end of summer, maybe.

* Interpreting this as not quite understanding the terms rather than utter negligence or even outright evilness, for now. But then "need to clean up first" is a lame excuse no matter what. Really.
2020-08-12 15:31
Jammer

Registered: Nov 2002
Posts: 967
Damn, why are you guys so hostile and pushing everytime GPL is even mentioned? That's really some Linux entitlement toxic shit. Maybe leave decision to the authors, will ya? ;)
2020-08-12 15:41
Groepaz

Registered: Dec 2001
Posts: 9532
The authors already decided, and choose GPL. It's that simple. Nothing to do with "hostile" at all. If you don't like how GPL works, don't choose GPL. It's that simple.
2020-08-12 16:21
spider-j

Registered: Oct 2004
Posts: 230
Quoting Jammer
That's really some Linux entitlement toxic shit.

If you open source your code of course you're entitled to chose whatever license you want. And if someone uses that code I would consider it the "normal" behaviour to respect that license. Wether it's on Linux, Windows or Amiga OS ;-)

And: the VICE project and it's components have a long sad "tradition" of code being used in other projects (even commercial ones) with many completely ignoring their license. I can understand that VICE coders are kind of frustrated by that.
2020-08-12 16:31
Jammer

Registered: Nov 2002
Posts: 967
I know that Groepaz always reminds of GPL compliance but he's usually quite formal so I get it. Krill's stance, on the other hand, was imho a hit below the belt in any discussion. Blame it on the heat, I guess? :D

BTW, gotta give a new version another go. Maybe my impressions will change.
2020-08-12 16:35
Groepaz

Registered: Dec 2001
Posts: 9532
Well, he is right in the sense that "when it's cleaned up" usually means "never". It IS a bad excuse :)
2020-08-12 19:21
AMB

Registered: Nov 2005
Posts: 14
Thanks for pointing me out to the MacOS version of SF2. I will be trying it for the coming days. And of course, thanks for your work to anyone involved in this promising project.
2020-08-12 19:36
Laxity

Registered: Aug 2005
Posts: 450
Thanks. I hope it works for you. :)
2020-08-12 20:54
Jammer

Registered: Nov 2002
Posts: 967
Quoting Groepaz
Well, he is right in the sense that "when it's cleaned up" usually means "never". It IS a bad excuse :)


Have some faith in humanity :D
2020-08-12 22:01
Krill

Registered: Apr 2002
Posts: 1521
Quoting Jammer
Krill's stance, on the other hand, was imho a hit below the belt in any discussion. Blame it on the heat, I guess? :D
Why "below the belt"? Not aware that i insulted anyone personally, nor did i intend to. And why the stance itself, not the delivery?

Heat or not, my opinion remains unchanged. :)
Good reasons have been mentioned by others.
2020-08-13 11:24
Laxity

Registered: Aug 2005
Posts: 450
The source code was made available yesterday morning.

Let me explain myself a bit as to why I didn't release the source code with the first release. As so many other things, it was based on a bad assumption, or disposition I should say. I wasn't expecting an uproar about it, because this is a niche application within a niche of our community. I was clearly wrong, as it seems several of you had strong feelings about this. My bad.

At this point I actually kind of regret having released anything before the editor was at a stage where internal data structures, code quality and capabilities are where I want them, but done is done.

One thing to speak in my favor, I hope, is that I've never done anything related to GPL and so have absolutely no experience with the procedures involved. I did get a bit emotional about the strong arming, sighing and prejudice about my intentions, but again, that's my mess and something I have to deal with.

So there it is.. The source is available, even if it's a mess in parts and has parts that are embarrassingly badly engineered. I got eager to get things working, and cut corners :) I feel a bit like I've put out my dirty underwear for show.

If any of you are having a look and find something that isn't quite up to par in terms of GPL, I'd appreciate any help that might fix it.
2020-08-13 12:52
Frantic

Registered: Mar 2003
Posts: 1456
@Laxity: That last post of yours, plus actually releasing the source, was exactly the right thing to do I think. Cool! Looks like an interesting editor, and I also appreciate that you've made it cross-platform! If anyone thinks the orderliness and structure of the code doesn't live up to some kind of standard, that's their problem.
2020-08-13 13:17
Laxity

Registered: Aug 2005
Posts: 450
100% vanity. :)
2020-08-13 13:40
cadaver

Registered: Feb 2002
Posts: 1135
Excellent, even on a cursory glance it's a hell of a lot better engineered than GT2. Also a bit more complex :)
2020-08-13 13:56
tlr

Registered: Sep 2003
Posts: 1391
Quoting Laxity
The source code was made available yesterday morning.

Let me explain myself a bit as to why I didn't release the source code with the first release. As so many other things, it was based on a bad assumption, or disposition I should say. I wasn't expecting an uproar about it, because this is a niche application within a niche of our community. I was clearly wrong, as it seems several of you had strong feelings about this. My bad.
Some of the feelings stem from people just wanting to compile it for their favourite platform and some are about principle.
Cross platform music editors are very popular from what I see. I guess it's because someone without having a c64 can make sid music without too high a threshold.

Quoting Laxity
One thing to speak in my favor, I hope, is that I've never done anything related to GPL and so have absolutely no experience with the procedures involved. I did get a bit emotional about the strong arming, sighing and prejudice about my intentions, but again, that's my mess and something I have to deal with.
I don't think the strong voices really were about your intentions. It's just the matter of principle. If it uses GPLd works inside, the source is to be shared and if someone waits too long it often gets forgotten in the end. You did the right thing!

Quoting Laxity
So there it is.. The source is available, even if it's a mess in parts and has parts that are embarrassingly badly engineered. I got eager to get things working, and cut corners :) I feel a bit like I've put out my dirty underwear for show.
Nah, that's going to be fine.

It looks to be a very fine program indeed! :)
2020-08-13 14:47
Groepaz

Registered: Dec 2001
Posts: 9532
@Laxity: Thumbs up! I can understand your reservations against showing the premature source - but really, this is not a problem in practise. Anyone looking at it knows that feeling :) "release early, release often" is the common way to do it :)

That said, there are a few things to consider regarding GPL

- you have put a GPL v3 license in the source package. you should *really* make sure this is actually what you want, and what the implications are (its quite different to the v2 in some regards). i can't explain this in a few words, but you should find more than enough info about GPL v2 vs GPL v3 on the net. (VICE and ReSID use v2 for that matter, with the "or later version" option)

- If you dont intend to change ReSID yourself, you should at least put a GPL v2 into the resid directories (actually, put the respective licenses into all the libs you are using). This avoids complications in the future.

- The source seems a bit "naked" to me. Depending on which GPL version you choose, you will have to provide everything required to build from source (that includes project files etc). also binary blobs like the driver .prg files can be a problem, those may require source too (with v3 i think this is a must, but it would be really nice in any case).

- Last not least, please add the license and contact info to your binary releases. That was actually one of the major reasons for me to even bring up the topic - when those things are missing, its usually a sign of someone trying to hide the fact he is using GPLd software.

I'd also suggest putting the source into a public repository, because that makes some things much easier. Totally your own choice, of course.

So - is anyone already looking into creating makefiles for linux? If noone else does, i will look into that, perhaps this weekend.
2020-08-13 15:30
Laxity

Registered: Aug 2005
Posts: 450
Thanks :)

I guess I can change it to v2 still, right?

What I did was look at what Cadaver provided with Goat, so I thought that was good enough for Jazz (except I got the license text from the interwebs). Contact info in form of physical address or email sufficient?

Driver sources aren’t required to run the software, and is more like a plugin. Drivers will be included later too. I guess from the next build we might have it where it makes sense. I would be surprised if that is a requirement, but hey - I know nothing about this stuff.

Would be great if you tried building for Linux. If you need any assistance, please let me know.

Thanks for the help so far.
2020-08-13 15:47
Groepaz

Registered: Dec 2001
Posts: 9532
Quote:
I guess I can change it to v2 still, right?

If you want to get really anal about it... technically the one you released is now GPL v3 licensed. BUT - since you are the only author, you can always re-license it (This becomes a lot more difficult once you accept contributions from other ppl). So yes, you can do it :)

Quote:
Contact info in form of physical address or email sufficient?

email, or even a website with a contact form, is fine.

Quote:
Driver sources aren’t required to run the software, and is more like a plugin. Drivers will be included later too. I guess from the next build we might have it where it makes sense. I would be surprised if that is a requirement, but hey - I know nothing about this stuff.

This topic can become *really* difficult, i have usually solved it in the past by simply providing all source :) This "plugin" debate is something ppl in the community have been arguing about quite a bit in the past - the general consensus seems to be that: when your host program and the plugins are the only existing combination (the plugins can be used in exactly one host programs), this is no different to linking them into the binary, with all implications (ie GPL "infection"). But i'm not a lawyer.... it's something to consider however. This restriction exists so you cant "break" GPL by just compiling all GPL code into "plugins" and load it dynamically into your program.
2020-08-13 15:51
iAN CooG

Registered: May 2002
Posts: 2787
> I feel a bit like I've put out my dirty underwear for show.

Oh don't worry, there is a niche market for that kind of fetish too. :D
2020-08-13 16:16
tlr

Registered: Sep 2003
Posts: 1391
Quoting Groepaz
- The source seems a bit "naked" to me. Depending on which GPL version you choose, you will have to provide everything required to build from source (that includes project files etc). also binary blobs like the driver .prg files can be a problem, those may require source too (with v3 i think this is a must, but it would be really nice in any case).

The .prg binaries are in a grey area IMO. Is there really always source for included firmware? e.g microcode, CPU management engine, WIFI chipset code, etc...
That said, it would be really nice to have source for that as well. :)

Quoting Groepaz
So - is anyone already looking into creating makefiles for linux? If noone else does, i will look into that, perhaps this weekend.

Please do! :)
2020-08-13 16:33
Laxity

Registered: Aug 2005
Posts: 450
Quote: Quoting Groepaz
- The source seems a bit "naked" to me. Depending on which GPL version you choose, you will have to provide everything required to build from source (that includes project files etc). also binary blobs like the driver .prg files can be a problem, those may require source too (with v3 i think this is a must, but it would be really nice in any case).

The .prg binaries are in a grey area IMO. Is there really always source for included firmware? e.g microcode, CPU management engine, WIFI chipset code, etc...
That said, it would be really nice to have source for that as well. :)

Quoting Groepaz
So - is anyone already looking into creating makefiles for linux? If noone else does, i will look into that, perhaps this weekend.

Please do! :)


A shit. It tried to reply on the underwear comment. :)

Those are prgs that you can load on any c64, emulator and now also sid factory. Those files just provide at chunk of meta-data the editor can interpret.
2020-08-13 18:53
JCH

Registered: Aug 2008
Posts: 182
I have now replaced GPL v3 with v2 in all SF2 archives at the blog, including the one with source codes.

The file included is the plain text version I found here.
2020-08-13 18:55
Laxity

Registered: Aug 2005
Posts: 450
Awesome, buddy. :)
2020-08-13 19:19
Groepaz

Registered: Dec 2001
Posts: 9532
I couldnt resist... i have it running natively. I had to add a couple missing includes here and there, and provide a platform file. Will fix the mess i made a bit and then post a link, stay tuned :)
2020-08-13 20:06
Groepaz

Registered: Dec 2001
Posts: 9532
So yay, here it is.... Linux binaries (NOT statically linked with SDL2): http://hitmen.c02.at/temp/SIDFactoryII_Linux_20200718.zip

Source with Makefiles and additions required to compile on Linux:
http://hitmen.c02.at/temp/SIDFactoryII_Source_20200718_Makefile..

Included is a really quick and dirty makefile (and completely untested variants of it for msys and macos), and a .patch file which has all the changes in it, so you can review and copy/change those files in your sourcetree (or just copy over the changed files. i only added a few missing includes, plus added platform files for linux)

If you merge all those things, in the future the only eventually still needed changes for linux will touch the makefile or the platform files.

cheers :)
2020-08-13 20:33
Laxity

Registered: Aug 2005
Posts: 450
Wow.. that was quick. Thank you!
2020-08-13 20:57
Groepaz

Registered: Dec 2001
Posts: 9532
There are still some flaws with those Makefiles... first obvious one reported by Mr.Ammo: if you compile on macos and it gives you a ton of errors, add -std=c++17 to FLAGS :) The same might be required on Linux, depending on your version of GCC
2020-08-13 21:10
Laxity

Registered: Aug 2005
Posts: 450
Yeah, needs c++17 for sure. We've got the macOS version already. Not that I know much about the mac really, but I did have to do a lot of changes to the code for Clang to agree with it, because it was written in Visual Studio, and the MS compiler is not following the standards fully and allowing thing that Clang will get really upset about :)

Looked over the diff. Looks like you only had to implement a copy of the macos platform for linux and add a few includes for making memset available. Nice.

I'll make sure to bring those over to the current work and extend it to support the new features.

I noticed the builds were crazy HUGE.:)
2020-08-13 21:15
tlr

Registered: Sep 2003
Posts: 1391
Quoting Groepaz
There are still some flaws with those Makefiles... first obvious one reported by Mr.Ammo: if you compile on macos and it gives you a ton of errors, add -std=c++17 to FLAGS :) The same might be required on Linux, depending on your version of GCC

Compiles on Ubuntu 20.04LTS, gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0, though with quite a few warnings (here: sf2-20200718_warnings.txt).
It seems to run fine, but I only loaded and played a demo song.

A rather weird anomaly is that selecting '..' in the file selector gives a modal warning about invalid file, but pressing enter there clears it and still goes to the parent directory.
2020-08-13 21:18
tlr

Registered: Sep 2003
Posts: 1391
Quoting Laxity
I noticed the builds were crazy HUGE.:)

tlr@sakura$ ls -l sf2
-rwxrwxr-x 1 tlr tlr 28679328 Aug 13 21:07 sf2
tlr@sakura$ strip -s sf2
tlr@sakura$ ls -l sf2
-rwxrwxr-x 1 tlr tlr 992208 Aug 13 21:16 sf2
tlr@sakura$

Better?
2020-08-13 21:20
Groepaz

Registered: Dec 2001
Posts: 9532
Quote:
We've got the macOS version already.

yes, sure. but some ppl prefer compiling on the commandline :)

it might actually be possible to remove the need to define this _SF2_whatever symbol, and use system specific symbols instead... so a single makefile will work for all of them. a good start would be to require _SF2_MACOS for macos, and not put the macos stuff in the "else" branches (instead put an #error there). In another step you can then replace those by system specific (defined by your compiler, or IDE) defines, like _WIN32 for windows. Oh well. it works either way for now :=)

edit: oh yeah, perhaps remove the -g from FLAGS (that will add debug symbols)
2020-08-13 22:01
JCH

Registered: Aug 2008
Posts: 182
The ".." file thing is a bug that we've fixed in the next build to come. You can use Backspace instead in Windows, hope that works in Linux too.
2020-08-13 22:02
tlr

Registered: Sep 2003
Posts: 1391
Quote: The ".." file thing is a bug that we've fixed in the next build to come. You can use Backspace instead in Windows, hope that works in Linux too.

Backspace works in linux too, thanks!
2020-08-13 22:12
Laxity

Registered: Aug 2005
Posts: 450
Quote: Quoting Groepaz
There are still some flaws with those Makefiles... first obvious one reported by Mr.Ammo: if you compile on macos and it gives you a ton of errors, add -std=c++17 to FLAGS :) The same might be required on Linux, depending on your version of GCC

Compiles on Ubuntu 20.04LTS, gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0, though with quite a few warnings (here: sf2-20200718_warnings.txt).
It seems to run fine, but I only loaded and played a demo song.

A rather weird anomaly is that selecting '..' in the file selector gives a modal warning about invalid file, but pressing enter there clears it and still goes to the parent directory.


Yeah, ok. I havn’t had initialization order warnings since coding for PS3, it’s not a standard level of warnings In Visual Studio, nor XCode. I guess you can win some speed on the cachelines, but for the purpose of this application, that seems like a waste of time.

I have some warning using clang, which sre all in reSID, else nothing.

The “..” bug is fixed. I actually thought it was in released source also.
2020-08-13 22:17
Groepaz

Registered: Dec 2001
Posts: 9532
i added -Wall in the makefile, which is what i always do... they are always worth fixing, IMHO, cleaner code does never hurt :) (i even use -Wextra -W for my own stuff)
2020-08-13 22:18
Laxity

Registered: Aug 2005
Posts: 450
Quote: Quote:
We've got the macOS version already.

yes, sure. but some ppl prefer compiling on the commandline :)

it might actually be possible to remove the need to define this _SF2_whatever symbol, and use system specific symbols instead... so a single makefile will work for all of them. a good start would be to require _SF2_MACOS for macos, and not put the macos stuff in the "else" branches (instead put an #error there). In another step you can then replace those by system specific (defined by your compiler, or IDE) defines, like _WIN32 for windows. Oh well. it works either way for now :=)

edit: oh yeah, perhaps remove the -g from FLAGS (that will add debug symbols)


I suck at makefiles - always hated them :) I added the define to VS, because that I know, and so as long as there were only those two platforms, all would be great. At least it’s only needed to select which platform class to instantiate, as I recall. :) I don’t really like ifdefs.
2020-08-13 22:22
tlr

Registered: Sep 2003
Posts: 1391
Quote: i added -Wall in the makefile, which is what i always do... they are always worth fixing, IMHO, cleaner code does never hurt :) (i even use -Wextra -W for my own stuff)

Just don't ask compyx. When you fixed all your warnings, he'll just pull out one more -W option to expose further stuff... ;)
2020-08-13 22:25
Laxity

Registered: Aug 2005
Posts: 450
Quote: Just don't ask compyx. When you fixed all your warnings, he'll just pull out one more -W option to expose further stuff... ;)

Haha. I’m not going to fix those. They are of absolutely no consequence. :) Except maybe for foundation structures, it might give a slight performance boost... :)
2020-08-13 22:28
tlr

Registered: Sep 2003
Posts: 1391
Quoting Laxity
Yeah, ok. I havn’t had initialization order warnings since coding for PS3, it’s not a standard level of warnings In Visual Studio, nor XCode. I guess you can win some speed on the cachelines, but for the purpose of this application, that seems like a waste of time.

No problem, just passing the information. If it's safe, then gpz should add -Wno-reorder to the flags to kill that warning.
There are a couple of signed/unsigned compare warnings in there (search -Wsign-compare). Most are obviously harmless, some could be worth checking at least.
2020-08-13 22:32
Laxity

Registered: Aug 2005
Posts: 450
Quote: Quoting Laxity
Yeah, ok. I havn’t had initialization order warnings since coding for PS3, it’s not a standard level of warnings In Visual Studio, nor XCode. I guess you can win some speed on the cachelines, but for the purpose of this application, that seems like a waste of time.

No problem, just passing the information. If it's safe, then gpz should add -Wno-reorder to the flags to kill that warning.
There are a couple of signed/unsigned compare warnings in there (search -Wsign-compare). Most are obviously harmless, some could be worth checking at least.


I just tried -Wall .. it's ridiculous.. It tells me when there are redundant characters after a semicolon. Jesus!

Yeah, the signed unsigned ones needs to be fixed!
2020-08-13 22:39
tlr

Registered: Sep 2003
Posts: 1391
Quote: I just tried -Wall .. it's ridiculous.. It tells me when there are redundant characters after a semicolon. Jesus!

Yeah, the signed unsigned ones needs to be fixed!


Here's with -Wno-reorder: sf2-20200718_warnings2.txt

Yeah, it's quite some work to fix stuff if it wasn't enabled all along. I now use "pedantic -Wall -Wextra -Wno-unused-parameter" on several projects (in C). It actually found me some bugs.
2020-08-13 22:55
Groepaz

Registered: Dec 2001
Posts: 9532
Yeah fixing a project retroactively is a huge PITA (we are doing this with VICE... and it did indeed expose a couple bugs as well, so its not completely pointless).
2020-08-13 23:37
Laxity

Registered: Aug 2005
Posts: 450
Ok. I have some work to do there. How utterly boring. :)
2020-08-14 13:41
Groepaz

Registered: Dec 2001
Posts: 9532
BTW, i have no clue at all on how to build a .deb - so if anyone wants to do that now, go ahead :)
2020-08-14 14:08
Stone

Registered: Oct 2006
Posts: 142
I have started using cmake for all my multi platform hobby projects. It saves me from all the hassle of maintaining multiple build systems. Even selecting clang as the compiler for Visual Studio is dead easy. I highly recommend clang btw, it produces very sensible warnings and does a better job of optimizing than the Microsoft compiler. Resid-fp without floating point optimizations is extremely heavy on the CPU...
2020-08-14 14:18
Groepaz

Registered: Dec 2001
Posts: 9532
cmake for something like this is super overkill. the makefile contains like 1 command :) but i should indeed have not explicitly used g++ in it. oh well. does it matter really?
2020-08-14 14:29
Stone

Registered: Oct 2006
Posts: 142
To each their own, but when I'm compiling for Windows, Linux and MacOS I don't think it's overkill at all, not even for the smallest of projects.
2020-08-14 14:36
Compyx

Registered: Jan 2005
Posts: 576
It does, use $(CXX) so the user's default compiler can be used (and changed on the commandline).

And, as tlr mentioned it needs more -W*.
2020-08-14 15:44
Groepaz

Registered: Dec 2001
Posts: 9532
yeah will do that kind of detail fixes once the other stuff is merged.

that said, i still recommend a public repo... it would be a lot less tedious to provide this kind of stuff :)
2020-08-14 16:12
Compyx

Registered: Jan 2005
Posts: 576
Yeah, a public source repo would help a lot.
2020-08-15 10:26
Laxity

Registered: Aug 2005
Posts: 450
We’re considering the option of putting it on GitHub. I have 0 experience with this, so a factor is that we’d like to retain control of the project at the time being. I’m not quite sure how that really works on GitHub. It would be excellent if one can have a private development branch and a public ditto. There’s a bit to learn. :) Also, I can't imagine that SID factory II is much of a target for modifications yet, or might even ever be.

Anyway, I appreciate all the input from you guys. Thanks for taking the time to look at it.
2020-08-15 10:42
Krill

Registered: Apr 2002
Posts: 1521
Why not put the repository on chordian.net? Full control. \=D/

(I don't trust github et al. either.)
2020-08-15 10:50
spider-j

Registered: Oct 2004
Posts: 230
Quoting Laxity
It would be excellent if one can have a private development branch and a public ditto.

I'd guess that actually noone cares about dev branches unless you have a bug in master. In both cases: it's really no problem to also have dev public.

I don't think many people have the hobby to check dev branches and making fun of the ugly code they find there ;-)

Of course – as Krill pointed out – self-hosting is an option to have full control if you're really concerned about that.
2020-08-15 11:18
Krill

Registered: Apr 2002
Posts: 1521
Quoting spider-j
Of course – as Krill pointed out – self-hosting is an option to have full control if you're really concerned about that.
And it may even be read-only for anyone but the admin. If someone requests merging in a patch, they'd just send a diff with the latest repository version.

Worst that can happen is that they decide to fork the project and put it on github et al. themselves, but that's how it is with free and open source. :)
2020-08-15 12:10
Groepaz

Registered: Dec 2001
Posts: 9532
First of all i wouldnt bother hiding a "development branch" - that only creates more work (someone contributes a fix - and then you cant just apply it, but have to merge it into your development branch). There will be very few ppl actually looking at the code anyway - and those who do should better see the current version, and not something from the last release.

I dont recommend self hosting either if you have no experience with that - again, it only creates more work with very little gain.

If you create a github project, you should get everything you want. You can just not grant anyone write access, so you have full control over whats in the repo. And everyone who wants to contribute fixes can clone the repo and send you a pull request, which is then very easy to merge (with a single click).

I dont like github all that much myself, but thats because i had many years of exposure to subversion before, and i am just too used to it (and it does all i need/want). If you dont know either, starting with git is probably the much better idea :) (warning: it can be very WTF at times)
2020-08-15 12:16
Krill

Registered: Apr 2002
Posts: 1521
Quoting Groepaz
I dont like github all that much myself, but thats because i had many years of exposure to subversion before, and i am just too used to it (and it does all i need/want). If you dont know either, starting with git is probably the much better idea :) (warning: it can be very WTF at times)
https://docs.github.com/en/github/importing-your-projects-to-gi.. =)

Maybe git is to github what car is to carpet, or Java to JavaScript.
2020-08-15 12:19
Groepaz

Registered: Dec 2001
Posts: 9532
One thing i seriously do NOT recommend is using github with subversion. That defeats the point and only creates more problems :)
2020-08-15 12:23
Laxity

Registered: Aug 2005
Posts: 450
Ok cool. Lot’s to consider. Thanks. We currently have it in an svn repo, as we’re three people working on it in different aspects of the project.
2020-08-15 13:40
Groepaz

Registered: Dec 2001
Posts: 9532
If you already have that, just expose it publicly for read access.... when someone wants to contribute a fix, he can just provide a "svn diff", easy enough :)
2020-08-16 22:47
spider-j

Registered: Oct 2004
Posts: 230
@Laxity: It looks you're still using very old resid and residfp versions. After manually grabbing current versions from VICE and libsidplayfp for my GT2 fork I saw that Leandro (the guy who seems to do most of the work on them at the moment) has them both as standalone repositories here:
https://github.com/drfiemost/resid
and here:
https://github.com/drfiemost/residfp
2020-08-18 22:24
Isildur

Registered: Sep 2006
Posts: 259
Thanks Groepaz, Linux binaries working great.
Also compilation running without any issues with default flags.
As a newborn Linux user I have only one issue, can't set it to executable. I mean all permissions and "Allow this file to run as a program" are set, but binary won't run this way, always asking to choose program to run with and opens with Python by default ;).
From Terminal "./sf2" working perfect. Tested on Linux Lite (Ubuntu fork). Thanks again!
2020-08-18 22:55
Groepaz

Registered: Dec 2001
Posts: 9532
when running from terminal works, then the executable flag is set correctly... perhaps the filemanager you are using is simply designed to not start executables on clicking them?
2020-08-19 00:22
Isildur

Registered: Sep 2006
Posts: 259
Nope, every other program is working fine, like Vice or C64debugger etc. (Thunar is default FM in Linux Lite).
Not a big deal since it starts from the terminal.
2020-08-19 00:43
Groepaz

Registered: Dec 2001
Posts: 9532
this is weird, in that case it should work. perhaps the ownership and flags must be different than they come out after compiling? try ls -al on the sf2 binary, and then on some binary that is working - compare the flags and owner. i dont know that filemanager, so cant help much further :)
2020-08-19 16:37
Compyx

Registered: Jan 2005
Posts: 576
On my Debian box with the Caja file manager (Nautilus 'clone'), the file manager seems to think sf2 is a shared library.

Permissions are the same as for example x64sc:
ls -la sf2
-rwxr-xr-x 1 compyx compyx 27679040 Aug 14 14:02 sf2

ls -la x64sc
-rwxr-xr-x 1 compyx compyx 14123256 Aug 18 16:06 x64sc


However, SF2 is a PIE executable, x64sc is not:
file sf2
sf2: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=5b6b88f773ad56120d738b4f181dc68661687d3f, stripped

file ~/vice-trunk/gtk3-build/src/x64sc 
/home/compyx/vice-trunk/gtk3-build/src/x64sc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=be2a63f76964e05d01919c1f1b928f408f78460c, with debug_info, not stripped


So it seems file managers get confused when given a pie executable. I tried adding -fno-pic to the FLAGS in Makefile, but that make the linker fail.

So, a nice little tidbit to figure out :)


BTW: Thunar is a file manager that's either part of Xfce4 or usually packaged with it. It's a nice tool.
2020-08-19 17:17
Groepaz

Registered: Dec 2001
Posts: 9532
Haha, here (KDE/Konqueror) it says sf2 is an executable program, and will not be started because of security reasons =D

Would have never noticed, i always run those things from cmdline anyway :)
2020-08-19 18:23
Compyx

Registered: Jan 2005
Posts: 576
A filthy workaround would be to create a .desktop file:

[Desktop Entry]
Type=Application
Version=2.0
Name=Sid Factory II
Comment=SID music editor
Path=/home/compyx/temp/SIDFactoryII_Source_20200718_Makefiles
Exec=/home/compyx/temp/SIDFactoryII_Source_20200718_Makefiles/sf2    
Terminal=false
Categories=Audio;AudioVideo


Write that as ~/.local/applications/SIDFactoryII.desktop

Obviously alter the Path and Exec parameters, and perhaps add Icon=<some-icon-file>

This should present "Sid Factory II" in the 'Sound & Video' submenu of an XDG compliant desktop's menu. (You may have to log out and back in).

Ofcourse this is a filthy hack and doesn't solve the problem. The problem is why the code needs -fPIC in the first place?
2020-08-19 18:36
Compyx

Registered: Jan 2005
Posts: 576
That hack also works for Gnome Hell, SID Factory II shows up in the garbage display that is Gnome Hell's "overview" of applications. Also works on Gnome Classic.
2020-08-19 19:20
spider-j

Registered: Oct 2004
Posts: 230
As someone living quite happily in "Gnome Hell" I wouldn't consider .desktop files a "hack", but the "way to go" anyway ;-)

Btw.: when I switch to XFCE Thunar won't open binary files here too.

And what groepaz said :-)

And last but not least here VICE is also pie:
[spider@havarie bin]$ file x64sc
x64sc: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=a965e4d950f6e083819728e464d09cba0575b793, with debug_info, not stripped
2020-08-19 19:27
Compyx

Registered: Jan 2005
Posts: 576
Well, .desktop files aren't a hack ofcourse, but using them when a file manager refuses to open a binary is, a bit, it hides the problem.

And I would also have never noticed sf2 not running from a file manager, I run most stuff from a terminal as well.

That said, can you run x64sc from a file manager with it being a 'pie'?
2020-08-19 19:45
spider-j

Registered: Oct 2004
Posts: 230
Quoting Compyx
That said, can you run x64sc from a file manager with it being a 'pie'?

No, not in Nautilus, not in Thunar.
And the only binaries that are *not* pie on both of my computers are the GNU compilers. Everything else in /usr/bin is pie.
2020-08-19 19:47
Compyx

Registered: Jan 2005
Posts: 576
Ah, my current compiles of vice are done with clang-10/11. Let's see what the old gcc 9.3 does.
2020-08-19 21:48
Compyx

Registered: Jan 2005
Posts: 576
Fuck, yep. GCC also produces pies.
2020-08-19 22:10
Isildur

Registered: Sep 2006
Posts: 259
Hack by Compyx gives me :)
"Failed to execute command "~/SidfactoryII/sf2" (not a directory)"
2020-08-19 22:11
Compyx

Registered: Jan 2005
Posts: 576
Does that path exist?

Wouldn't surprise me if ~ doesn't get expanded to /home/$USER. So perhaps use the full path?
2020-08-19 22:29
Isildur

Registered: Sep 2006
Posts: 259
It's shortened to post it here, full path is in .desktop file.
Also I noticed in Krusader and Doublecmd SF2 runs without any issues. Great.
2020-08-19 22:50
Compyx

Registered: Jan 2005
Posts: 576
Meanwhile I noticed adding -no-pie to the FLAGS in Makefile results in a non-pie binary that can be run from a file manager. But I'm getting reports that might not work on KDE.
2020-08-19 22:53
Isildur

Registered: Sep 2006
Posts: 259
@Compyx yeah, thank you! That's it. Now SF2 is fully operational on Linux Lite. "FLAGS=-O2 -Wall -g -no-pie"
2020-08-19 22:55
Compyx

Registered: Jan 2005
Posts: 576
Great!

Perhaps at some point someone can explain why I needed -no-pie in the first place?

But who cares, it works! :)
2020-08-19 23:28
Groepaz

Registered: Dec 2001
Posts: 9532
Quote:
"FLAGS=-O2 -Wall -g -no-pie"

make this "FLAGS=-O2 -Wall -Wno-reorder -no-pie" for less useless warnings and much smaller executable :)
2020-08-20 00:11
Isildur

Registered: Sep 2006
Posts: 259
Quote: Quote:
"FLAGS=-O2 -Wall -g -no-pie"

make this "FLAGS=-O2 -Wall -Wno-reorder -no-pie" for less useless warnings and much smaller executable :)


This is great!
SF2 previously:28,6 MB, and now: 1,3 MB
cool :)
2020-08-20 00:14
CreaMD

Registered: Dec 2001
Posts: 2744
I'm just here to say. What a community. Wow! Love you guys.
2020-08-20 10:44
Isildur

Registered: Sep 2006
Posts: 259
I raw-tweaked a bit file "color.cpp" to set less eye burning colors.


If someone interested just replace original with these:
		m_Colors[0x00] = 0x00000000;		// Black
		m_Colors[0x01] = 0xffbdbdbd;		// White
		m_Colors[0x02] = 0xff844b40;		// Red
		m_Colors[0x03] = 0xff2f504a;		// Green
		m_Colors[0x04] = 0xff364469;		// Blue
		m_Colors[0x05] = 0xffbd9441;		// Yellow
		m_Colors[0x06] = 0xffff8080;		// Light Red
		m_Colors[0x07] = 0xff69c68b;		// Light Green
		m_Colors[0x08] = 0xff6b72a5;		// Light Blue
		m_Colors[0x09] = 0xffe7be8e;		// Light Yellow
		m_Colors[0x0a] = 0xff800000;		// Dark Red
		m_Colors[0x0b] = 0xff006000;		// Dark Green
		m_Colors[0x0c] = 0xff1e222f;		// Dark Blue
		m_Colors[0x0d] = 0xff707000;		// Dark Yellow
		m_Colors[0x0e] = 0xffc0c0c0;		// Lighter grey
		m_Colors[0x0f] = 0xff888888;		// Light grey
		m_Colors[0x10] = 0xff707070;		// Grey
		m_Colors[0x11] = 0xff25282d;		// Dark Grey
		m_Colors[0x12] = 0xff202020;		// Darker Grey
		m_Colors[0x13] = 0xff5d2323;		// Darker Red
		m_Colors[0x14] = 0xff004800;		// Darker Green
		m_Colors[0x15] = 0xff000060;		// Darker Blue
		m_Colors[0x16] = 0xff4c4c00;		// Darker Yellow
2020-08-20 12:35
JCH

Registered: Aug 2008
Posts: 182
Interesting coincidence, the next version of SF2 will have color definitions and color schemes.
2020-08-20 17:44
Jammer

Registered: Nov 2002
Posts: 967
Quoting Isildur
I raw-tweaked a bit file "color.cpp" to set less eye burning colors.


I'd use that! <3
2020-08-20 20:04
DKT

Registered: Aug 2004
Posts: 77
You never choose wrong with Isildur's choices ;)
BTW It's fun to see hyenas pick at Laxity's work and tear it apart in all ways ;)
2020-08-20 21:52
Mixer

Registered: Apr 2008
Posts: 330
UI scaling, plz?
2020-08-20 22:55
Isildur

Registered: Sep 2006
Posts: 259
Quote: UI scaling, plz?

+1
2020-08-21 22:57
Laxity

Registered: Aug 2005
Posts: 450
Quote: I raw-tweaked a bit file "color.cpp" to set less eye burning colors.


If someone interested just replace original with these:
		m_Colors[0x00] = 0x00000000;		// Black
		m_Colors[0x01] = 0xffbdbdbd;		// White
		m_Colors[0x02] = 0xff844b40;		// Red
		m_Colors[0x03] = 0xff2f504a;		// Green
		m_Colors[0x04] = 0xff364469;		// Blue
		m_Colors[0x05] = 0xffbd9441;		// Yellow
		m_Colors[0x06] = 0xffff8080;		// Light Red
		m_Colors[0x07] = 0xff69c68b;		// Light Green
		m_Colors[0x08] = 0xff6b72a5;		// Light Blue
		m_Colors[0x09] = 0xffe7be8e;		// Light Yellow
		m_Colors[0x0a] = 0xff800000;		// Dark Red
		m_Colors[0x0b] = 0xff006000;		// Dark Green
		m_Colors[0x0c] = 0xff1e222f;		// Dark Blue
		m_Colors[0x0d] = 0xff707000;		// Dark Yellow
		m_Colors[0x0e] = 0xffc0c0c0;		// Lighter grey
		m_Colors[0x0f] = 0xff888888;		// Light grey
		m_Colors[0x10] = 0xff707070;		// Grey
		m_Colors[0x11] = 0xff25282d;		// Dark Grey
		m_Colors[0x12] = 0xff202020;		// Darker Grey
		m_Colors[0x13] = 0xff5d2323;		// Darker Red
		m_Colors[0x14] = 0xff004800;		// Darker Green
		m_Colors[0x15] = 0xff000060;		// Darker Blue
		m_Colors[0x16] = 0xff4c4c00;		// Darker Yellow


Hey buddy,

Can I steal those colors for a color scheme? Looks pretty neat?
2020-08-21 23:17
Isildur

Registered: Sep 2006
Posts: 259
Quote: Hey buddy,

Can I steal those colors for a color scheme? Looks pretty neat?


Of course :)
2020-08-22 22:53
Laxity

Registered: Aug 2005
Posts: 450
Quote: Of course :)

\o/ Thanks.. The editor now has a color scheme named Isildur.
2020-08-23 01:14
Isildur

Registered: Sep 2006
Posts: 259
Quote: \o/ Thanks.. The editor now has a color scheme named Isildur.

;)
If you have template ready I could make few more.
Btw I saw nice and clean theme by JCH on FB.
2020-08-23 08:37
JCH

Registered: Aug 2008
Posts: 182
Thanks. I based it on a 5-color palette from Coolors. I'll see if I can make some more schemes.

Maybe it's prudent to wait until the next version of SF2. It has a color scheme INI file system and you have much greater control there, including hitting a button to reload the color scheme instead of restarting SF2 each time.
2020-08-25 11:02
JCH

Registered: Aug 2008
Posts: 182
Could you post a link to the Linux binaries build again, please? Someone on Reddit has been asking for it.
2020-08-25 11:11
Groepaz

Registered: Dec 2001
Posts: 9532
http://hitmen.c02.at/temp/SIDFactoryII_Linux_20200725.zip

(this time without debug info, so binaries are much smaller)
2020-08-25 11:15
JCH

Registered: Aug 2008
Posts: 182
Super, thanks.
2020-08-25 11:19
Groepaz

Registered: Dec 2001
Posts: 9532
also should be 20200825 ... bah :)
2020-09-11 14:36
JCH

Registered: Aug 2008
Posts: 182
SID Factory build 20200911 has been released today.

The main features of this build are a help overlay (use F12), color schemes (browse these with Ctrl+F7) and driver update 11.02 with commands for pulse program index, tempo change and main volume.

As always you can get the binaries here: http://blog.chordian.net/sf2/

The source codes are now also available at GitHub for the first time.
2020-09-11 14:48
Groepaz

Registered: Dec 2001
Posts: 9532
great! should i send you a pull request with the missing makefiles and the gpl? :)
2020-09-11 14:50
Compyx

Registered: Jan 2005
Posts: 576
How do I build on Linux? Seems it's very windows-centric? Seems there's two Makefile's for MacOS.
2020-09-11 17:41
youtH

Registered: Aug 2003
Posts: 8
Quoting Groepaz
great! should i send you a pull request with the missing makefiles and the gpl? :)


Please have a look in the 'linux' branch on Github. There is a Makefile in the root. I also incorporated your changes in the linux specific platform file.

Was hoping to include an official linux build, but I could not properly test it in my virtual ubuntu environment. Especially the keybindings; for macOS we needed to override a few of the bindings, maybe we need to do the same for linux? If someone could test if all the bindings work or some need replacing, JCH can also make the proper overlay images, which are also os specific.

Any help/feedback on linux build would be appreciated!
2020-09-11 17:47
youtH

Registered: Aug 2003
Posts: 8
Quoting Compyx
How do I build on Linux? Seems it's very windows-centric? Seems there's two Makefile's for MacOS.


Please have a look in the 'linux' branch on Github. No instructions yet, but 'make dist' should do the trick.

Please note that overlays do not work yet as their content is os specific and we do not know if all the keybindings are in their proper place.

There is one separate Makefile for macos in the /macos folder with specific macOS app bundling stuff. There is duplication which can probably be improved later. I see there is an old Makefile in the SF2Converter but you can discard that. The one in the root builds sf2 and sf2converter.

Feedback appreciated ;)
2020-09-11 19:09
Compyx

Registered: Jan 2005
Posts: 576
After doing a 'git checkout linux' I did manage to build a Linux binary.

You might consider changing a few variables in the Makefile:
CC is meant to contain the C compiler, not the C++ compiler, so you should use CXX
You also use CC_FLAGS, which is non-standard, nothing wrong with that, but the standard would be CXXFLAGS (CFLAGS for C).
Same with LINKER_FLAGS, the standard variable would be LDFLAGS. And for linking perhaps use $(LD) and add 'LD=$(CXX)' in the Makefile after 'CXX=g++'.

Nitpicking, I know, but it would make it easier for people to override the compiler, linker and flags in a standard way :)
2020-09-11 19:38
JackAsser

Registered: Jun 2002
Posts: 1716
Quote: After doing a 'git checkout linux' I did manage to build a Linux binary.

You might consider changing a few variables in the Makefile:
CC is meant to contain the C compiler, not the C++ compiler, so you should use CXX
You also use CC_FLAGS, which is non-standard, nothing wrong with that, but the standard would be CXXFLAGS (CFLAGS for C).
Same with LINKER_FLAGS, the standard variable would be LDFLAGS. And for linking perhaps use $(LD) and add 'LD=$(CXX)' in the Makefile after 'CXX=g++'.

Nitpicking, I know, but it would make it easier for people to override the compiler, linker and flags in a standard way :)


Nitpicking aside, this is proper nitpicking.

Never seen LD assigned to CXX though
2020-09-11 19:58
youtH

Registered: Aug 2003
Posts: 8
Quoting Compyx

Nitpicking, I know, but it would make it easier for people to override the compiler, linker and flags in a standard way :)


I have only limited linux/c++/makefile experience so I am not surprised the Makefile is flawed :) Once I had the macOS build I thought I could have a go at extending the experience I had from that to a linux build.

But since neither Laxity, JCH or myself actually use linux, we will not find issues ourselves or be able to properly fix and test them, so input and pull requests are welcome!
2020-09-11 21:09
Compyx

Registered: Jan 2005
Posts: 576
Quote: Nitpicking aside, this is proper nitpicking.

Never seen LD assigned to CXX though


We use g++ or clang++ as a linker for vice, otherwise vte won't link, usually though LD=$(CC) should work fine.
2020-09-11 21:13
Compyx

Registered: Jan 2005
Posts: 576
Quote: Quoting Compyx

Nitpicking, I know, but it would make it easier for people to override the compiler, linker and flags in a standard way :)


I have only limited linux/c++/makefile experience so I am not surprised the Makefile is flawed :) Once I had the macOS build I thought I could have a go at extending the experience I had from that to a linux build.

But since neither Laxity, JCH or myself actually use linux, we will not find issues ourselves or be able to properly fix and test them, so input and pull requests are welcome!


You may want to start with merging the 'linux' branch into master. Having to check out a separate branch (which is out of sync) for Linux feels weird.
2020-09-11 23:18
Groepaz

Registered: Dec 2001
Posts: 9532
Quote:
You may want to start with merging the 'linux' branch into master.

this :)

as for distribution - i wouldnt bother much. just make sure it builds correctly. packaging is usually up to those who make the distros. it shouldnt be required for something simple like this either. if you really care, a proper "make install" target is the way to go, imho - but it will require configuration options for various things. i'd rather fix the code so a plain binary distribution works from whatever location.
2020-09-12 07:14
youtH

Registered: Aug 2003
Posts: 8
Quoting Groepaz
Quote:
You may want to start with merging the 'linux' branch into master.

this :)


Done. Linux branch is merged to master. Good luck ;)
2020-09-12 13:45
Groepaz

Registered: Dec 2001
Posts: 9532
Compiles with almost zero warnings (just some harmless "unchecked return values of fread"), and works fine from the "artifacts" directory after "make dist". i think you can just zip that up for an oldschool binary distribution, leave more sophisticated packaging to whoever wants to do it =P
2020-09-12 13:57
tlr

Registered: Sep 2003
Posts: 1391
Quote: Compiles with almost zero warnings (just some harmless "unchecked return values of fread"), and works fine from the "artifacts" directory after "make dist". i think you can just zip that up for an oldschool binary distribution, leave more sophisticated packaging to whoever wants to do it =P

+1

Seems to build fine here on Ubuntu 20.04.1LTS. Good work guys!
2020-09-12 16:41
youtH

Registered: Aug 2003
Posts: 8
Quoting Groepaz
Compiles with almost zero warnings (just some harmless "unchecked return values of fread"), and works fine from the "artifacts" directory after "make dist". i think you can just zip that up for an oldschool binary distribution, leave more sophisticated packaging to whoever wants to do it =P


Thanks! Only thing is, I have no clue if the keyboard bindings are all working. Can anyone shed some light on that? I am using a virtualbox image to test but it already has a weird keyboard layout so I can't properly test it.
2020-09-12 16:44
Groepaz

Registered: Dec 2001
Posts: 9532
MMMh, i dont know the program good enough to check this - but it's an SDL app, i dont see why there would be differences between windows/linux/mac. At least in VICE there are no such problems with the keyboard, unless you are using keys that you shouldnt use in the first place ("media" keys for example)
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Harry Potthead
Honcho
EGO/Lethargy
obliterator918/Strate
Krill/Plush
iceout/Avatar/HF
fredrikr
Guests online: 39
Top Demos
1 Uncensored  (9.7)
2 Coma Light 13  (9.7)
3 Edge of Disgrace  (9.6)
4 Comaland 100%  (9.6)
5 Unboxed  (9.6)
6 The Shores of Reflec..  (9.6)
7 Lunatico  (9.6)
8 Remains  (9.5)
9 C=Bit 18  (9.5)
10 D50  (9.5)
Top onefile Demos
1 Cuarentenauta  (9.5)
2 Listen to Your Eyes  (9.5)
3 Dawnfall V1.1  (9.5)
4 Rewind  (9.5)
5 Instinct  (9.5)
6 Daah, Those Acid Pil..  (9.5)
7 Crystal Gazer  (9.5)
8 Smile to the Sky  (9.5)
9 The Tuneful Eight [u..  (9.5)
10 Bad Boy  (9.5)
Top Groups
1 Fossil  (9.4)
2 PriorArt  (9.4)
3 Booze Design  (9.4)
4 Censor Design  (9.3)
5 Performers  (9.3)
Top Logo Graphicians
1 Mermaid  (9.4)
2 Pal  (9.3)
3 Jailbird  (8.9)
4 Elko  (8.9)
5 Shine  (8.8)

Home - Disclaimer
Copyright © No Name 2001-2020
Page generated in: 0.215 sec.