Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Cannot build on Linux: missing pcx2snes #9

Closed
jneen opened this issue May 14, 2020 · 41 comments
Closed

Cannot build on Linux: missing pcx2snes #9

jneen opened this issue May 14, 2020 · 41 comments

Comments

@jneen
Copy link

jneen commented May 14, 2020 •
edited

Hi all,

I'm attempting to follow the guide for building this project, but the Makefile is attempting to run a program called pcx2snes, which doesn't seem to exist in this project or in any package. I tried using the one from optixx (https://github.com/optixx/snes/tree/master/vram/tools), but a) it seems only to be for windows, and b) I get mysterious "File not found" pop-up boxes when I attempt to use it through wine. My setup for wine is just an executable script on the PATH called pcx2snes with the contents:

#!/bin/bash
exec wine /path/to/pcx2snes.exe "$@"

Any tips on how I'm recommended to install this tool? I've come up blank unfortunately.
@jneen
Copy link
Author

jneen commented May 14, 2020

The tool is very unspecific about which file was not found:
2020-05-14@May:05:1589470781_366x216

This is what's in the log at the time:
2020-05-14@May:05:1589470817_3908x273

It's also followed up by "Run-time error '5': Invalid procedure call or argument", which sounds like a NPE?

@bazz1tv
Copy link
Owner

bazz1tv commented May 14, 2020

Hello @jneen
I see you are located in Tokyo! As someone who is big on Japanese, I would like to say おはようございます 🙇 snestrackerに興味を持ってくれてありがとうございます！

Thanks as well for your documentation and screenshots. The pcx2snes dependency is a key issue that I will address immediately, and that should get you compiling successfully. Stay tuned.

@bazz1tv
Copy link
Owner

bazz1tv commented May 14, 2020

For now, you may clone https://github.com/bazzinotti/pcx2snes, make it and then get the binary into your PATH.

@jneen
Copy link
Author

jneen commented May 15, 2020

Ah, thank you - I should actually change that as I moved to Toronto nearly a year ago >< (and i'm not japanese...). Thank you for the tip, I'll try that!

@jneen
Copy link
Author

jneen commented May 15, 2020

Aaand it worked like a charm. Now I'm on to a separate problem, which is that I seem to be missing jdkmidi/world.h, which I also can't seem to find in any package manager. Is there a preferred source for that as well?

@bazz1tv
Copy link
Owner

bazz1tv commented May 15, 2020

I see the problem. libjdkmidi needs to install its dev files.
For now, simply try this from the snestracker folder:

pushd pc/ext/libjdkmidi/c++/out.Linux ; make ; sudo make install-dev ; popd ; make

Let me know how it goes. I will be taking what I learn from this experience to improve the build system.

@bazz1tv
Copy link
Owner

bazz1tv commented May 15, 2020 •
edited

Once you get snestracker compiled, the tracker will be located at pc/bin/st and the debugger at pc/bin/std.

Since there is no current documentation yet available for this limited capability pre-alpha state of the software, the least I can do is offer minimal guidance.

Debugger

I recommend loading an SPC into the debugger program first, it is fascinating. That can be done through the commandline pc/bin/std /path/to/spcfile.spc or through the GUI directly File->Open. The README has some details on what can be done in the debugger as well, although lacking directions. Hopefully you figure out some cool, interesting things in there!

Tracker

When you are ready to use the tracker, you open it up similarly to std. However, you should only open it without any arguments, like pc/bin/st. At this time the files must be opened from the GUI, File->Open ST-Song

I'm going to attach some song files that I made as I went along developing; just little sounds and bits of music. They will include random BRR samples / instruments too. See the attached zip file.

If you start from scratch;
To actually do anything useful in the tracker, you'll need BRR samples. Incase you need help with that, they can be ripped from existing SPCs via std by going to the DSP tab and right clicking the DIR entry that you want to dump.
A context menu will appear in which you can "Rip BRR" and save the file. Unfortunately, the BRR loop data is not saved at this time. Eventually, std will dump STI (snestracker instrument) file format which will include the BRR loop and ADSR settings when ripping.

Eventually, the tracker will be able to handle other file formats like WAV, perhaps including other popular formats like mp3, aiff, which will ultimately be imported into BRR for use in the tracker.

Once you have at least one BRR sample, you simply load the Samples from the tracker main window (self explanatory). To start writing music, you will need to have some experience with tracker keyboard controls, as the controls are based on FastTracker II / MilkyTracker keyboard, with some other unique keyboard short cuts. No time to explain at the present time, sorry!

DISCLAIMER

Use this software at your own risk. I cannot be held responsible for any ill consequences suffered by trying this software.

I intend to improve the file formats be forward and backward compatible, but this is currently not the case. Songs made on this version may not load up in a future version. That is, not until I stabilize my file formats (already got something in mind).

snestracker_demo.zip

@jneen
Copy link
Author

jneen commented May 15, 2020

Thank you so much! I've made significant progress, but I'm now stuck at the fact that boost_system-mt doesn't seem to be provided by any Arch package (some are saying it's not compatible with g++ >5?)

@jneen
Copy link
Author

jneen commented May 15, 2020

I do have a libboost-system.so, but no -mt...?

[0: jneen@garlic snestracker ] -> *master $
; y -Qs boost
local/boost 1.72.0-2
    Free peer-reviewed portable C++ source libraries - development headers
local/boost-libs 1.72.0-2
    Free peer-reviewed portable C++ source libraries - runtime libraries

[0: jneen@garlic snestracker ] -> *master $
; y -Ql boost-libs | grep system
boost-libs /usr/lib/libboost_filesystem.so
boost-libs /usr/lib/libboost_filesystem.so.1
boost-libs /usr/lib/libboost_filesystem.so.1.72
boost-libs /usr/lib/libboost_filesystem.so.1.72.0
boost-libs /usr/lib/libboost_system.so
boost-libs /usr/lib/libboost_system.so.1
boost-libs /usr/lib/libboost_system.so.1.72
boost-libs /usr/lib/libboost_system.so.1.72.0

@bazz1tv
Copy link
Owner

bazz1tv commented May 15, 2020 via email

@bazz1tv
Copy link
Owner

bazz1tv commented May 15, 2020

I've confirmed the above sed command works flawlessly. 👍

@jneen
Copy link
Author

jneen commented May 16, 2020

Thank you, that did work. I'm now at the point where it's attempting to compile the tracker, and it seems a number of constants are undefined, including SPCCMD_PLAYSONG, SPCDRIVER_CODESTART, CBIT and CBIT_RLE among others.

@bazz1tv
Copy link
Owner

bazz1tv commented May 16, 2020

Those messages would only come from the spc driver not being built before the pc-side apps. Running the top-level Makefile will build both in the proper order, so I'm wondering if you were running make from the pc/ directory?

if that doesn't work; you might want to try make clean; make from the top-level directory and copy paste your output as a reply.

Other thoughts: You were able to compile the debugger, right? Hang in there, you're are so freaking close

@jneen
Copy link
Author

jneen commented May 17, 2020

I am building from the root level, and using make clean. Here's the entire output: https://gist.github.com/jneen/c59d6f2a143c81a9c005b202b34ed990

@bazz1tv
Copy link
Owner

bazz1tv commented May 17, 2020 •
edited

Hm, your build process looks good though.

Take a look at your generated pc/tracker/apuram.h

The scripting responsible for generating that file was executed from your make invocation. https://gist.github.com/jneen/c59d6f2a143c81a9c005b202b34ed990#file-out-L120-L134

That comes from line 57 in the top-level Makefile: https://github.com/bazzinotti/snestracker/blob/45792372eab70c70365d1364d2b9e41e0372fad9/Makefile#L57-L73

The generated apuram.h will look like this when generated properly:

#pragma once

struct TrackerApuRam
{
	uint8_t padding[33];
	uint8_t ticks;
	uint8_t spd;
	uint8_t dspdir_i;
	uint16_t instrtable_ptr;
	uint16_t sequencer_ptr;
	uint8_t sequencer_i;
	uint16_t patterntable_ptr;
	uint8_t extflags;
	uint8_t mvol_val;
	uint8_t evol_val;
	uint8_t esa_val;
	uint8_t edl_val;
	uint8_t efb_val;
	uint8_t c0_val;
	uint8_t c1_val;
	uint8_t c2_val;
	uint8_t c3_val;
	uint8_t c4_val;
	uint8_t c5_val;
	uint8_t c6_val;
	uint8_t c7_val;
	uint8_t padding2[0xffdf];
} __attribute__((packed));
#define SPCDRIVER_FILENAME "tracker.spc"
#define SPCDRIVER_CODESIZE 0x406
#define SPCDRIVER_CODESTART 0x202

#define CBIT 0x7
#define CBIT_NOTE 0x0
#define CBIT_INSTR 0x1
#define CBIT_VOL 0x2
#define CBIT_FX 0x3
#define CBIT_FXPARAM 0x4
#define CBIT_RLE 0x5
#define CBIT_RLE_ONLY1 0x6

#define REPORT_TRACKER_INCROW 0x0
#define REPORT_TRACKER_SETROW 0x1
#define REPORT_TRACKER_SETPATTERN 0x2

#define EXTFLAGS_REPEATPATTERN 0x0
#define EXTFLAGS_SKIP_ECHOBUF_CLEAR 0x1

#define SPCCMD_NOP 0x0
#define SPCCMD_READRAM 0x1
#define SPCCMD_WRITERAMBYTE 0x2
#define SPCCMD_PLAYSONG 0x3
#define SPCCMD_STOPSONG 0x4

What does your pc/tracker/apuram.h look like?

@jneen
Copy link
Author

jneen commented May 17, 2020 

cat pc/tracker/apuram.h
#pragma once

struct TrackerApuRam
{
	uint8_t padding[33];
	uint8_t ticks;
	uint8_t spd;
	uint8_t dspdir_i;
	uint16_t instrtable_ptr;
	uint16_t sequencer_ptr;
	uint8_t sequencer_i;
	uint16_t patterntable_ptr;
	uint8_t extflags;
	uint8_t mvol_val;
	uint8_t evol_val;
	uint8_t esa_val;
	uint8_t edl_val;
	uint8_t efb_val;
	uint8_t c0_val;
	uint8_t c1_val;
	uint8_t c2_val;
	uint8_t c3_val;
	uint8_t c4_val;
	uint8_t c5_val;
	uint8_t c6_val;
	uint8_t c7_val;
	uint8_t padding2[0xffdf];
} __attribute__((packed));
#define SPCDRIVER_FILENAME "tracker.spc"
#define SPCDRIVER_CODESIZE 0x406



[0: jneen@garlic snestracker ] -> *master $ 
;

@bazz1tv
Copy link
Owner

bazz1tv commented May 17, 2020 •
edited

Everything is being generated well except that which WLA-DX should be outputting. This appears to be a problem with your wla-dx.

When you explicitly run

/home/jneen/src/wla-dx/binaries/wla-spc700 -t snes_driver/apu/memorymap_defs.i 2>/dev/null

you should get the output:

#define SPCDRIVER_CODESTART 0x202

But you are not getting that output, right? When running properly, the above command without redirecting stderr would give the following:

$ /home/jneen/src/wla-dx/binaries/wla-spc700 -t snes_driver/apu/memorymap_defs.i
#define SPCDRIVER_CODESTART 0x202
INCLUDE_DIRECTIVES: ROMBANKS/ROMBANKMAP wasn't defined.

If you are getting any other output, please let me know.

@jneen
Copy link
Author

jneen commented May 17, 2020

that binaries directory is empty. there is a directory in build-wla/binaries, and that gives:

[2: jneen@garlic snestracker ] -> *master $ 
; /home/jneen/src/wla-dx/build-wla/binaries/wla-spc700 -t snes_driver/apu/memorymap_defs.i
#define SPCDRIVER_CODESTART 0x202

@jneen
Copy link
Author

jneen commented May 17, 2020

i changed my env to point to that directory and did a make clean; make and it gave me the same error though

@bazz1tv
Copy link
Owner

bazz1tv commented May 17, 2020

When the WLAPREFIX is set correctly, all wla binaries will be executed from the one specified location. In your build log, why were some of your wla binaries being run from the right directory, while others were not? scratches head That is not normal!!

Let's review
Correctly set, your env.conf has WLAPREFIX = /home/jneen/src/wla-dx/build-wla/binaries/ with the trailing slash

If you are still having the same issue, post an updated make clean; make build output.

Confirm that all of your wla invocations are being run from the right location.

@bazz1tv
Copy link
Owner

bazz1tv commented May 17, 2020

I'm checking my project code for an error regarding this WLAPREFIX usage.

P.S. you will be the first person to build from this latest build system besides myself so I consider you an early adopter and would like to thank you so much for your involvement thus far.

@jneen
Copy link
Author

jneen commented May 17, 2020

no worries! i'm happy to spend some time refactoring the build if you're open to it.

@jneen
Copy link
Author

jneen commented May 17, 2020

Ohhhh it was wrong in env.conf, but correct in my shell environment. Trying again...

@jneen
Copy link
Author

jneen commented May 17, 2020

...and, no - it's the same error.

@bazz1tv
Copy link
Owner

bazz1tv commented May 17, 2020

Could you post the build log please?

@bazz1tv
Copy link
Owner

bazz1tv commented May 17, 2020 •
edited

(Without yet seeing the Build log) I have a hunch what will fix your current problem; try the following:
make clean ; rm snes_driver/Makefile ; make

@jneen
Copy link
Author

jneen commented May 17, 2020

https://gist.github.com/jneen/34263adf88f807be330ebd32abbe23c1

I'll give that a go as well!

@bazz1tv
Copy link
Owner

bazz1tv commented May 17, 2020

hm your binaries all are correctly prefixed now. So that's good. Everything looks good. So what is the content of your pc/tracker/apuram.h file now, then?

Regarding refactoring: First, let's just get it successfully compiling on your end. We could discuss what you have in mind afterwards. I will leave my brainstorm on the matter here below. It's not an urgent read tho.

Well, my first plan is to compile a listing of "lessons learned" directly from this issue and correctly implement them so that the current build system is stabilized. This includes an intention to move towards git submodules. Our progress here is serving to bring a functioning build system for any developers that want to dip into snestracker development.

Then I want to focus on the next milestone which is releasing binaries for the first limited functionality but usable prototype for early adopters to try out. (without going into the details of what needs to be addressed for that release just yet).

I'm definitely interested in incorporating this early prototype with a survey that will enable early adopters to give feedback on the app, and what they want the most in the next iteration, things they love about it, things they dislike, etc.

It would be cool to see the early prototype be used in song competition as well, such as a battle on https://battleofthebits.org

@jneen
Copy link
Author

jneen commented May 17, 2020

Good news - I managed to fix it, I had wla-build instead of build-wla...? I'm not sure how it ended up that way. Thanks for all the help getting this built! ...though I'm still not sure which is the thing I'm supposed to run now?

As far as making this process easier, I think the first thing I'd suggest is including the git-based dependencies (i.e. ones that aren't in most system package managers) as sumbodules or subdirectories to this repository (like the custom wla-dx repo for example). This way we can eliminate the requirement of configuring filepaths for the build system to find these things.

@jneen
Copy link
Author

jneen commented May 17, 2020

Also, my interest in this project comes mainly from a composer's perspective - really interested in doing some sound design and composition for the snes. So I'd be happy to credit back to this project for whatever I write with it :]

@bazz1tv
Copy link
Owner

bazz1tv commented May 17, 2020 •
edited

That's great advice. Please see #9 (comment) ; In an earlier post in this thread I gave some initial directions, including some sample songs and samples in a zip archive. Be sure to check that out. (look for the big header text)

One of the most important things is I wanted to mention is when you go to do an SPC Export, just ignore all the fields and press 'Export' on the new window that appears. The fields are not yet customizable; that's in the works. You can even inspect your new SPC in the std debugger :)

I'm sprinting to get you caught up since you are the earliest adopter and there is no documentation yet. Documentation and/or video tutorial would help countless others get started using this software, so I'm going to make that a priority.

@jneen
Copy link
Author

jneen commented May 17, 2020

Neat! I've successfully run the program. It's showing up 1/2 size on my HiDPI display though - is there a UI zoom option for the UI framework you're using?

@bazz1tv
Copy link
Owner

bazz1tv commented May 17, 2020

Credits
Thank you, in the future I would be happy to receive proper credit. Something along the lines of

SNES Music and Sound effects created with snestracker
  . https://bazz1.com (author website)
  . https://github.com/bazzinotti/snestracker (project site)

Would be great!

I also accept donations via Paypal to mbazzinotti@gmail.com

Regarding High DPI
There was a UI zoom option but I disabled it due to slight unclarity of the zoomed UI. I could have a stab at getting a custom patch developed for you to test.

@bazz1tv
Copy link
Owner

bazz1tv commented May 17, 2020 via email

@jneen
Copy link
Author

jneen commented May 17, 2020

Yeah!

Just for context so it's clear what I mean:

2020-05-17@May:05:1589747263_1834x1067

@bazz1tv
Copy link
Owner

bazz1tv commented May 17, 2020 via email

@jneen
Copy link
Author

jneen commented May 17, 2020 via email

@bazz1tv
Copy link
Owner

bazz1tv commented May 18, 2020

Here is a quick patch to get you going with scaling the window up.

diff --git a/pc/tracker/main.cpp b/pc/tracker/main.cpp
index 4c4d943e..9b030615 100644
--- a/pc/tracker/main.cpp
+++ b/pc/tracker/main.cpp
@@ -44,7 +44,7 @@ int init_sdl(SDL_Window **sdlWindow, SDL_Renderer **sdlRenderer, SDL_Texture **s
   atexit(SDL_Quit);
 
   *sdlWindow = SDL_CreateWindow("snes tracker", SDL_WINDOWPOS_CENTERED,
-                SDL_WINDOWPOS_CENTERED, width, height, SDL_WINDOW_HIDDEN);
+                SDL_WINDOWPOS_CENTERED, width, height, SDL_WINDOW_HIDDEN | SDL_WINDOW_RESIZABLE);
   *sdlRenderer = SDL_CreateRenderer(*sdlWindow, -1, SDL_RENDERER_ACCELERATED);// | SDL_RENDERER_PRESENTVSYNC);
 
   if (*sdlWindow == NULL)

@bazz1tv
Copy link
Owner

bazz1tv commented May 18, 2020

Apply the patch (manually or with git apply), then run make. you will now be able to resize and scale the window the same way you would resize any window in your window manager.

bazz1tv added a commit that referenced this issue May 18, 2020
@bazz1tv
[boost] remove -mt extension as that has antiquated
15796d5 
Helps issue #9 on Github
bazz1tv added a commit that referenced this issue May 19, 2020
@bazz1tv
Merge branch 'submodules' (#9)
4088166 
Improves on mostly build issues discovered from #9, including:

- pcx2snes dependency
- boost libs antiquated -mt suffix
- libjdkmidi internal dep proper handling
- Bringing in all "local" tools and libraries as submodules
- Window resizing / zoom ability

* submodules: (23 commits)
  [tracker] buff up the sdl init code
  #9 [tracker|debugger] allow window resizing as a simple scaling zoom
  Clarify the build doc
  update Building doc
  [submodule] update libgme_m
  [jdkmidi] need -fpermissive for mingw 64-bit
  #9 [boost] remove -mt extension as that has antiquated
  support libgme_m (load from tracker binary location)
  [submodule] update libgme_m
  [std] copy cursor files so app can run outside of build directory
  fix libjdkmidi building locally
  appropriately handle libgme_m libraries being installed 'locally'
  [submodules] fix error handling
  [submodules] update Building doc
  [submodules] error when make fails
  fix bug in genmake regarding new pcx2snes integration
  [submodule] update pcx2snes
  [jdkmidi] avoid configure scripts from being changed automatically after building
  silence mkdir when dir is already built
  formatting
  ...
@bazz1tv bazz1tv mentioned this issue May 19, 2020
Closed
@bazz1tv
Copy link
Owner

bazz1tv commented May 19, 2020 •
edited

@jneen I've worked everything discussed in this thread (aside from the new #10) into the recent update that is now present in master branch. I've manually verified that snestracker is building well across all supported platforms, and they were running well enough to load and play an stp (snestracker proj) file with visual synchronization.

To catch up on git, (just incase) I would recommend making a fresh clone of snestracker repo, removing your individual copies of my other projects that have been converted into submodules, and following the newer Building.md.

(Simply FYI) From here on out I have a couple main goals ahead

  1. Get the extendable file formats rolled out. This should allow snestracker to become as compatible as possible front and backwards to the native file formats as they improve.

  2. Roll out some early tutorials that demonstrate my workflow with snestracker and the debugger as one cohesive unit; help early adopters such as yourself get afloat.

  3. (pending on 1) , have std rip sti (snestracker instruments), which will include BRR loop point info as well as associated hardware ADSR setting.

Best Regards,

@bazz1tv
Copy link
Owner

bazz1tv commented May 23, 2020

Since the main issue of resolving the pcx2snes dependecy is resolved, I will now mark this issue as closed. Thanks for helping snestracker development!

If there's anything else I can do, please feel free to file an issue or email.

@bazz1tv bazz1tv closed this as completed May 23, 2020
@RowanDDR RowanDDR mentioned this issue Oct 15, 2020
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jneen @bazz1tv