Horny Source code on Github

@kas1e

Absolutely. A car can only have one driver: see Lynch's "Mulholland Drive", the Cowboy scene

@kas1e

If I make any real progress, I'll gladly put it back.
So far, I'm really just playing around.

Some of the stuff I'm doing may not be too popular:
I really prefer to use Interface pointers, and I've been adding them to the code. This may not be a popular choice.

I may also change variable types from BYTE WORD LONG to int8 int16, int32, again to be more aligned with the current OS4 standard.


I'm not sure if these will be wanted.. I pretty much just play by myself some times.

Very soon I'll hunt down the unfreed signal. Unless someone else get it first.

There's also a warning about the wrong Application interface index, but I only get that when I ran from workbench. (easily fixed)

The CAMD code sorted ports by "in" and "out". This is a common mistake. I removed this filter, and also raised the max number of ports fropm 16 to 24. Still not enough, I'll either raise it again or _properly_ set it for unlimited ports. Yes, I ahve a LOT of CAMD ports here, and more coming soon. Also SHOULD be able to create new CAMD ports by name. I'm not sure the current setup allows that.

Sorry about the late reply. I had a bit of trouble logging in here. George has kindly fixed it for me.

I'm open for suggestions, and if _some_ oif my changes are not wanted I'll gladly provide smaller updates with just the stuff that is wanted.

LyleHaze

@LyleHaze

Quote:
If I were to work on the code, I'd do the same. We're not heading for a cross-platform release, so why not stick with what's natural to OS4? Interface pointers help make the code clearer because you know where the individual functions come from.

Quote:
Absolutely. And again, I'd do the same.

Quote:
Could it be that the code still opens Application Library interface version 1, while you really need to get version 2 instead?

Quote:
Yes. I'd like to remind OS4 MIDI users that the USB MIDI driver allows port name aliases, so filtering MIDI ports based on ".in" and ".out" is not reliable because the port name extension may not be there at all.

@Lyle
Will be good if you can share what you have for now, so we can made pull request to Timo's github repo, so all will be there and no one else will need doing the same.

If you can share current sources (just some packed archive), i can made all the other stuff like making a pull request for Timo's repo, etc.

Because if not do it right now, chances that it all will die in time very high as usuall :) But if commit out what you have (your listed changes are enough for commit for sure), then anyone else who will every checking that will have it with all dirty-work done.

kas1e:
As soon as I have a working build I will either return it to GitHub or give it to someone to do that for me.

Right now I'm adding code for Library/Interface/Class opening and closing.

Then I'll track down the missing signal.

After that I'll "check it in" one way or another. There ARE more bugs, many are GUI related, and I suspect it's from the use of macros.
Removing them would be a BIG job.. likely more than I am willing to try.

Let's see how much I can get done tonight before I pass out.
Getting old is no fun at all. :)

Lyle

[edit].. Mad typing again tonight. LOVE the CherryMX Brown keyboard. :)
HornyOS4 now opens it's own libs and classes.
-lauto and -lraauto have been removed from the makefile.

It SEEMS to still open, though I have not done much with it yet.

Time to sleep, tomorrow I'll hunt down the hanging signal.

Lyle

[edit2]
Add at the end of
void EntferneCamd(void) {
(near Midi.c line 220)

if(-1 != playsig)
{
IExec->FreeSignal(playsig);
playsig = -1;
}

NOW maybe I can get some sleep.

[edit 3]
Compiles clean against -Wall

@Lyle

Fantastic job! What a night!

HornyOS4Ver1.4_Source.readme:

This is the first edit of HornyOS4 since the release of source code.

So far, I have:
removed key requirement
fixed an unfreed signal
expanded CAMD cluster selection
Changed variable types to int/uint
removed #ifdef OS4 conditions
added library pointers
removed #libauto from makefile
added warnings to makefile
replaced deprecated functions
bumped version to 1.4
added a *.debug build to makefile

And likely more I have forgotten.

There is more to be done, but this is a good point to get it back into GIT.
I have not yet run the program much more than loading an SMF and playing it. But that seems to work well enough.


BIG thanks to Timo Kloss for releasing the code.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Kas1e:
If you are willing to put these back into the GIT, please email lylehaze @gmail.com so I can reply with the source.

Thank You
LyleHaze

@Lyle
Cool ! I got your sources in mail, was able to fork and commit it all, bug before pull-request i checked if i can build it with latest gcc as before, and it bring me that error:

Quote:

As the same code was in original, that probabaly mean that after adding -werror it stop compiles on newer gcc as something problematic. Maybe you on older gcc where it compiles fine even with -werror ?

Also another errors which happens even if i remove -werror from makefile:

Quote:

Checked, and those ones seems come from updated beta classes which public SDK do not have, so no one except those who in beta-team will be able to compile it :(

@kas1e

That brings up the big question..

Why are you not on the beta team?

@Skateman
I am in of course. But i do check everything on latest public SDK, not beta one, because if users who in not beta-team can't compile it, that mean that sources will collect dust.

In other words, i am in beta, but all need to be compiled over public SDK so we have more pplz works on anything.

@kas1e

Great and ofcourse you are... I should have known better...

@kas1e

Thank You

There aer quite a few GUI classes that are opened in oca.c but not declared in oca.h

I missed that.

Mine has been fixed, I can send it to you or you can fix it up from there.
Once oca.h is corrected, just include it in any source file needing gadget classes declared.


Thanks for that.
Actually I'm kinda surprised that the only problem was an omissioon in a header file. There was a LOT of fast editing going on, something was sure to get missed.

updated oca.h is below.

[edit] Button, Scroller, and Slider gadgets are all in the public release
SDK53.30 .. hopefully updating the oca.h file and including it as needed
will fix the problem.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// oca.h
#ifndef OCA_H
#define OCA_H

#include <proto/intuition.h>

#define MAJ_REV 53

// Libraries
extern struct AslIFace *IAsl;
extern struct DiskfontIFace *IDiskfont;
extern struct GraphicsIFace *IGraphics;
extern struct IconIFace *IIcon;
extern struct IntuitionIFace *IIntuition;
extern struct LocaleIFace *ILocale;
extern struct UtilityIFace *IUtility;
extern struct WorkbenchIFace *IWorkbench;

// Gadget Classes
extern struct ClassLibrary *BitmapBase;
extern Class *BitmapClass;

extern struct ClassLibrary *ButtonBase;
extern Class *ButtonClass;

extern struct ClassLibrary *CheckBoxBase;
extern Class *CheckBoxClass;
extern struct CheckBoxIFace *ICheckBox;

extern struct ClassLibrary *ChooserBase;
extern Class *ChooserClass;
extern struct ChooserIFace *IChooser;

extern struct ClassLibrary *ClickTabBase;
extern Class *ClickTabClass;
extern struct ClickTabIFace *IClickTab;

extern struct ClassLibrary *GetFileBase;
extern Class *GetFileClass;
extern struct GetFileIFace *IGetFile;

extern struct ClassLibrary *GetScreenModeBase;
extern Class *GetScreenModeClass;
extern struct GetScreenModeIFace *IGetScreenMode;

extern struct ClassLibrary *IntegerBase;
extern Class *IntegerClass;
extern struct IntegerIFace *IInteger;

extern struct ClassLibrary *LabelBase;
extern Class *LabelClass;

extern struct ClassLibrary *LayoutBase;
extern Class *LayoutClass;
extern struct LayoutIFace *ILayout;

extern struct ClassLibrary *ListBrowserBase;
extern Class *ListBrowserClass;
extern struct ListBrowserIFace *IListBrowser;

extern struct ClassLibrary *RadioButtonBase;
extern Class *RadioButtonClass;
extern struct RadioButtonIFace *IRadioButton;

extern struct ClassLibrary *ScrollerBase;
extern Class *ScrollerClass;
extern struct ScrollerIFace *IScroller;

extern struct ClassLibrary *SliderBase;
extern Class *SliderClass;
extern struct SliderIFace *ISlider;

extern struct ClassLibrary *SpaceBase;
extern Class *SpaceClass;

extern struct ClassLibrary *StringBase;
extern Class *StringClass;
extern struct StringIFace *IString;

extern struct ClassLibrary *WindowBase;
extern Class *WindowClass;
extern struct WindowIFace *IWindow;


//
// Opens all libraries, classes, devices
// reads all args and tooltypes
// returns RETURN_OK, else RETURN_FAIL
//
int32 openAll(int argc, char **argv);

// always safe to call, handles any intermediate states
// displays any given reason by errMessage()
// ALWAYS returns RETURN_FAIL
int32 closeAll(CONST_STRPTR reason);

// use any available output, or create one if needed
void errMessage(CONST_STRPTR reason);

// easy OpenLibrary & GetInterface in one
// no need to store LibraryBase, as long as closeInterface is used to cleanup
// displays error details by errMessage if needed
APTR openInterface (CONST_STRPTR lib_name, int32 lib_vers,
CONST_STRPTR int_name, int32 int_vers);
void closeInterface (APTR interface);

// IIntuition->OpenClass() with error text output
APTR openClass(CONST_STRPTR className, uint32 classVers, Class **classPtr);

#endif
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

@Lyle
Quote:

Used fixed one, include it in all files where i have those issues, and it bring some conflicts about extern struct ClassLibrary *....Base things being declared already in proto files of SDK, so comment them out and all builds then.

The only issues remain with -werror are thos ones:


Quote:

And another one:

Quote:

Its like, in both cases it overflow last "0" of buffer probabaly, because once i set in first case not 1024, but 1023, and in second case not 512, but 511, all compiles fine without errors.

Maybe for time being we need to remove "-werror" from makefile, at least all will compiles and later someone can take care about ?

I also ajust makefile a little, so it now much smaller, as well as can be used and on cross-compiler, and natively.

@all
Ok checked-rechecked all and create pull request to Timo's repo!

https://github.com/timoinutilis/midi-sequencer-amigaos/pull/1

Use strlcat(), it's much safer.

Simon

Hi!

Here I am finally! I will check the pull request soon.

I wanted to say something before, but couldn't log in, and now I guess it's late. Anyway:

In the last year I got several requests for the keyfile from Vampire users. Some people are actually making music with Horny. V1.3 works ok on OS3, so I guess bugfixes are not super important for them, but going the OS4 only route is still a pity.

Personally I think it's better to stay compatible with all flavors of Amiga. From a programmer's perspective I also prefer to use modern systems, but Amiga has a quite special situation :/

Are there ways to compile OS4 style programs for OS3? Is there a modern GCC on OS3?

Anyway, I'm still impressed with the work you have done for Horny and it makes me happy to see interest in my old software :)

@Timo
Quote:

Nope.

Quote:

Issue there will be that as you can see, only os4 devs want to do something, because on os4 programm give issues. So, we can't expect that os3 devs will fix anything, if for them all works fine already.

In end of all, we can keep in your repo HornyGCC as "os4 only", and anyone can fix pure "Horny" directory for os3 build.

Or, pure os4 version can be handled on forked version. All the new changes in my forked repo already, so if you against of "pure os4", we can just continue in my forked repo, and to be seen if any os3 developer will do anything later. Later if you want you can merge it, or not merge :)

Personally, as i see it, no one willing to add any new functionality there, that we all there want it just to make interface looks fine on os4, and that all :)

Hi,
Is it OK to report a crash in 1.3 version or wait and check new binaries? Its not related to GUI but Prefs and MIDI Clusters, probably...

@mr2
There is new binaries (pure and debug one) of latest code changes:

http://kas1e.mikendezign.com/aos4/horny/Horny_test1.zip

Test this one. If there will be crash, then run HornyOS4.debug to reproduce crash again, and then send crashlog.

Yeap, its still there...
No need to run debug. Its always the same.
Disconnect all MIDI devices. Run Timi/SoftSyn then Horny. Enter Project/Settings/Midi Ports. You will see empty Outputs, No
Midi Cluster.
Try to change it with cycle gadget below to Timi/Softsyn. It's not possible and when trying to close Project Settings
window, bang, the crash.
To avoid this situation you have to open Phonolith or connect MIDI keyboard. Sth which appears in Midi Cluster window. Then
you can change
it to Timi/SoftSyn or sth else without the crash.
If its not enough or not place to discuss I may contact you by email




Crash log for task "HornyOS4"
Generated by GrimReaper 53.19
Crash occured in module newlib.library.kmod at address 0x01B22B44
Type of crash: DSI (Data Storage Interrupt) exception
Alert number: 0x80000003

Register dump:
GPR (General Purpose Registers):
0: 80808080 53F83BD0 00000000 CD804300 5431A390 00000080 53F83C00 00000000
8: CD804300 03000000 5431A390 54696D69 000007C8 53F5D328 00000000 54CD4340
16: 6F8D13EC 00000000 00000000 00340014 02270000 02270000 14FE1CC0 00000000
24: 58494CD2 00000000 24422284 00000000 00000000 02270000 152BE0D8 53F83BD0


FPR (Floating Point Registers, NaN = Not a Number):
0: nan 0 0 0
4: 0 455.8 27.8 0
8: 0 4.5036e+15 455.8 255
12: nan 65536 0 0
16: 0 0 0 0
20: 0 0 0 0
24: 0 2.65249e-315 4.23883e-270 nan
28: 0 0 9.88131e-324 1.51001e-296

FPSCR (Floating Point Status and Control Register): 0x82000000


SPRs (Special Purpose Registers):
Machine State (msr) : 0x0002F030
Condition (cr) : 0x51CC9DA0
Instruction Pointer (ip) : 0x01B22B44
Xtended Exception (xer) : 0x018233AC
Count (ctr) : 0x00000000
Link (lr) : 0x00000000
DSI Status (dsisr) : 0x01842B34
Data Address (dar) : 0x00000000



680x0 emulated registers:
DATA: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ADDR: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
FPU0: 0 0 0 0
FPU4: 0 0 0 0



Symbol info:
Instruction pointer 0x01B22B44 belongs to module "newlib.library.kmod" (HUNK/Kickstart)

Stack trace:
native kernel module newlib.library.kmod+0x000305a4
module HornyOS4 at 0x6F899100 (section 5 @ 0x1D0DC)
module HornyOS4 at 0x6F8D13DC (section 5 @ 0x553B8)
module HornyOS4 at 0x6F8D1444 (section 5 @ 0x55420)
native kernel module newlib.library.kmod+0x000020ac
native kernel module newlib.library.kmod+0x00002d5c
native kernel module newlib.library.kmod+0x00002ef0
HornyOS4:_start()+0x170 (section 1 @ 0x16C)
native kernel module dos.library.kmod+0x000255c8
native kernel module kernel+0x0003e7b4
native kernel module kernel+0x0003e7fc

PPC disassembly:
01b22b3c: 7d270039 and. r7,r9,r0
01b22b40: 40820018 bne- 0x1B22B58
*01b22b44: 91680000 stw r11,0(r8)
01b22b48: 38a5fffc subi r5,r5,4
01b22b4c: 39080004 addi r8,r8,4

System information:

CPU
Model: AMCC PPC440EP V1.3
CPU speed: 799 MHz
FSB speed: 133 MHz
Extensions: