[fpc-pascal] Re: Linux sound (especially MIDI) programming: ALSA?
http://sourceforge.net/projects/fpalsa/ http://sourceforge.net/projects/humus/ -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Linux-sound-especially-MIDI-programming-ALSA-tp5688908p5690300.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Linux sound (especially MIDI) programming: ALSA?
Wimpie Nortje wrote: On 2012/05/06 05:49 PM, Mark Morgan Lloyd wrote: Wimpie Nortje wrote: I have used ALSA to record sound. It was some time ago, I think on Kubuntu 10.04 or so. I can send you some code I used but I have no idea whether it will work under newer Linux's Thanks, but since it's specifically MIDI I'm interested in it might not be relevant. Can you remember which Pascal interface to the ALSA libraries you were using? I think I've seen two, but I've not yet checked to see whether they were actually minor variants of the same thing. The readme file says: ALSAPAS (ALSA library for Pascal) Version 0.9.7, September 2003. Copyright (c) 2002-2003, Pedro Lopez-Cabanillas p...@bigfoot.com Hence http://perso.wanadoo.es/plcl/alsapas/alsapas-en.html -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Linux sound (especially MIDI) programming: ALSA?
leledumbo wrote: http://sourceforge.net/projects/fpalsa/ http://sourceforge.net/projects/humus/ Thanks for those. Also http://perso.wanadoo.es/plcl/alsapas/alsapas-en.html so as I thought there appears to be (at least) two sets of ALSA bindings: fpalsa and alsapas. Noted HuMuS, but that appears to be for PortAudio. However using that as a seed I get to http://breakoutbox.de/pascal/pascal.html#PortAudio which claims to include PortMidi support- this is supposedly cross-platform but requires an additional library which might not be available on all distreaux. Also MIDI is very much the poor cousin and operating support is patchy, so since I've got ALSA working I'm reluctant to risk breaking anything. Since running on anything other than Linux is not a significant priority, I think I'll probably start off with by doing a comparison of fpalsa and alsapas, and writing code that will support either if possible. If I could also code to support PortMidi that would be a bonus, but by no means essential: I'm trying to knock together a MIDI transposer for my own use, and testbed some techniques for another project. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ObjectBinaryToText - how to write only selected property?
On Sat, 5 May 2012 18:15:51 +0200 Krzysztof dib...@wp.pl wrote: Hi, ObjectBinaryToText method can save object structure to string, but how save only some propertys? ObjectBinaryToText only converts between to formats. It does not save object structures. That is done by TWriter. TWriter normally saves only those properties that differ from the default value. If you provide an ancestor it will save only those properties that differ from the ancestor. I could use RTTI and TypeInfo, but ObjectBinaryToText can parse property hierarchy (Propery1.Subproperty1.Color etc). Or how I can save and read object from string without object name? Example: I am creating simple theme manager which save settings of some control (e.g. TEdit) and must read it not paying attention to the component name (Edit1, Edit2, Edit3 etc...) Must work like a template. See TReader.ReadRootComponent. If you have a component without csDesigning then it will not set the name. If you want to use your theme manager with some designer components (e.g. the components on a Lazarus or MSEGui designer) then you have to write a driver that returns the right name. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : [fpc-pascal] Reversing bit-order of byte
On 04-05-12 14:53, Koenraad Lelong wrote: On 04-05-12 14:31, Thomas Schatzl wrote: ... Compared to the other variants (e.g. with the multiplies, except for the table lookup) you already save a lot of cycles - although I guess they would be sufficiently fast anyway, considering the typical uart speeds. Thomas Hi Thomas, My processor flags : -Wpstm32f103rb -Cparmv7m. The #23 is no typo, I need to reverse 9 bits. I'm using 9 bit synchronous transmission. My first usart-tests were at 4Mbps. The person that made the driver recommends max. 6Mbps. Hi, I tested some things this weekend. Strange things happen ;-) The code does not work. Trying to debug with gdb, around the code I got an error, something like 'recovering from a double fault'. After searching the STM32 forum of ST I found that some toolchains assemble the rbit instruction in a wrong way. Someone made a work-around : .word 0xFxAyFA9y //RBIT Rx,Ry x, y = 0 to F My Freepascal version is this : .word 0xFA90 .word 0xF0A0 Then when I disassemble in gdb, I get rbit r0,r0 Disassembling with objdump gives a strange result. I'm going to try this as soon as I can. Regards, Koenraad Lelong. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] InstantFPC and argv
On Mon, May 7, 2012 12:21, Mattias Gaertner wrote: On Sat, 5 May 2012 15:04:05 +0200 (CEST) Tomas Hajny xhaj...@hajny.biz wrote: On Sat, May 5, 2012 14:13, Mattias Gaertner wrote: . . ExecuteProcess is only a simple utility function. All posix platforms can start a process with another environment. By default they use the current. Indeed. But InstantFPC works not only on posix platforms but also on WinXX and OS/2 at least if I remember correctly (and there's no reason why it couldn't be used even on Dos with e.g. 4DOS). All of them allow passing a different environment to the child process, but the implementation is obviously always different. That means that you need to replicate the platform specific implementation of that 'wrapper' for all supported platforms within InstantFPC. The implementation for unix is only a few lines. I guess for winxx and os/2 too. 54 lines for WinXX, 144 for OS/2 and 278 for GO32v2 (all without the additional platform specific implementation for changing the passed environment). I don't know about dos, but as fallback TProcess can be used, which already implements this x-platform. Not yet for OS/2 nor GO32v2, but yes, this would probably be a better option than including that stuff directly in InstantFPC if going down that route (of changing environment for the child process). . . A const in the main script is only accessible by the program, not by the used units. There are obviously solutions for that. However, I assume that the main use case for such scripts is writing a complete script in one file (the main program). Many perl/php/python scripts use modules. I don't see why it should be different for fpc scripts. In fact, I already have a few shared units for my instantfpc scripts. The used units need a way to find out the current script path. I understand that the preferences vary (personally, I'd probably compile such a bigger executable permanently). Anyway, it may be useful occasionally and as I mentioned, solutions exist (e.g. by defining the interface of such modules in a way allowing to pass the location from the main script either directly when invoking the functions having such a need or indirectly by initializing the location by changing a variable declared within the respective unit/module at the beginning of the script, or by declaring the variable in the main script as external and accessing it from the unit). Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Runs correctly when debugging.
Thanks, Henry, Can you give any more information about how it fails? It's a SIGSEGV. The library is the Allegro library version 5.0.6. The error is inside an internal procedure that uploads a texture to OpenGL context, and it is used by other Allegro functions (i.e. loading pictures from file, building text fonts, etc.). Initially I suspected that I didn't use the right data types, but after revisiting and fixing some of them it I'm pretty sure I'm using the right ones. I don't know what can I say. :-/ You may have to set the fpu exception mask if you're talking to c code, as a quick guess (search the archives for how). Don't know why this works with debugging enabled, though. I've revise the command-line options list and the only one I've find is that: -Cfx Select fpu instruction set to use, see fpc -i for possible values I don't know how can it help. :-? Regards, Guillermo Martínez ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ObjectBinaryToText - how to write only selected property?
On 5 May 2012 18:15, Krzysztof dib...@wp.pl wrote: I could use RTTI and TypeInfo, but ObjectBinaryToText can parse property hierarchy (Propery1.Subproperty1.Color etc). Out of interest, I have written an extended RTTI unit which is used in the tiOPF project. All the functions in that unit support what I call property paths, which means you can get and set properties like 'myobject.Propery1.Subproperty1.Color' on a object. The unit is called tiRTTI.pas, and tiOPF is hosted on SourceForge. The unit handles nil valued sub-properties correctly as well. The tiRTTI unit has minimal dependency on the other tiOPF units, so it will be very easy to make it a pure stand-alone unit. http://sourceforge.net/projects/tiopf/ -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] InstantFPC and argv
On Mon, 7 May 2012 13:34:50 +0200 (CEST) Tomas Hajny xhaj...@hajny.biz wrote: On Mon, May 7, 2012 12:21, Mattias Gaertner wrote: On Sat, 5 May 2012 15:04:05 +0200 (CEST) Tomas Hajny xhaj...@hajny.biz wrote: [...] The implementation for unix is only a few lines. I guess for winxx and os/2 too. 54 lines for WinXX, 144 for OS/2 and 278 for GO32v2 (all without the additional platform specific implementation for changing the passed environment). Where do got those numbers? TProcess for winxx only needs a few lines to set the environment: I don't know about dos, but as fallback TProcess can be used, which already implements this x-platform. Not yet for OS/2 nor GO32v2, but yes, this would probably be a better option than including that stuff directly in InstantFPC if going down that route (of changing environment for the child process). . . A const in the main script is only accessible by the program, not by the used units. There are obviously solutions for that. However, I assume that the main use case for such scripts is writing a complete script in one file (the main program). Many perl/php/python scripts use modules. I don't see why it should be different for fpc scripts. In fact, I already have a few shared units for my instantfpc scripts. The used units need a way to find out the current script path. I understand that the preferences vary (personally, I'd probably compile such a bigger executable permanently). It's not big. The RTL lacks little functions for scripts. For example download an URL, get a list of files in a directory, load a xml file, test a RE. Running pascal programs as scripts is only the first step. The next step is to provide a bunch of units that make commons tasks one liners. That's why people use perl et al. Anyway, it may be useful occasionally and as I mentioned, solutions exist (e.g. by defining the interface of such modules in a way allowing to pass the location from the main script either directly when invoking the functions having such a need or indirectly by initializing the location by changing a variable declared within the respective unit/module at the beginning of the script, or by declaring the variable in the main script as external and accessing it from the unit). True. But recompilation is slow and should be avoided if possible. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] InstantFPC and argv
In our previous episode, Mattias Gaertner said: It's not big. The RTL lacks little functions for scripts. For example download an URL, get a list of files in a directory, load a xml file, test a RE. Running pascal programs as scripts is only the first step. The next step is to provide a bunch of units that make commons tasks one liners. I agree. I've added some minor stuff in recent versions: - base64 encode/decode in one function (instead of streaming only) - symbolic has a simple quickevaluate to quick do calculations ( like 2+4+6, even simple var substitution is possible ) I recently copied the TProcess wiki example to get the output of an exe in a string for the 3rd or 4th time, so that was my next target. A bit like ExecuteProcess, one variant that operates on a whole cmdline (but only the most basic separation) and one array of const style. That's why people use perl et al. That is IMHO a bridge too far :-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] InstantFPC and argv
On Mon, May 7, 2012 14:26, Mattias Gaertner wrote: On Mon, 7 May 2012 13:34:50 +0200 (CEST) Tomas Hajny xhaj...@hajny.biz wrote: 54 lines for WinXX, 144 for OS/2 and 278 for GO32v2 (all without the additional platform specific implementation for changing the passed environment). Where do got those numbers? TProcess for winxx only needs a few lines to set the environment: The numbers are for existing ExecuteProcess implementations (my original point was that if you needed to change the environment, you could not use ExecuteProcess as provided by the RTL and had to replicate the ExecuteProcess implementations within InstantFPC instead). Your (later) proposal to move to TProcess solves that better, of course. . . It's not big. The RTL lacks little functions for scripts. For example download an URL, get a list of files in a directory, load a xml file, test a RE. Running pascal programs as scripts is only the first step. The next step is to provide a bunch of units that make commons tasks one liners. That's why people use perl et al. . . KIDDING need_to_respond=0 Calling wget, ls or grep already are one liners. ;-) /KIDDING Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : [fpc-pascal] Reversing bit-order of byte
On 7 May 2012, at 13:26, fpc-pascal-requ...@lists.freepascal.org wrote:
Message: 4
Date: Mon, 07 May 2012 12:59:58 +0200
From: Koenraad Lelong ko...@de-brouwerij.be
Subject: Re: RE : RE : [fpc-pascal] Reversing bit-order of byte
To: fpc-pascal@lists.freepascal.org
Message-ID: 4fa7ab2e.9050...@de-brouwerij.be
Content-Type: text/plain; charset=UTF-8; format=flowed
On 04-05-12 14:53, Koenraad Lelong wrote:
On 04-05-12 14:31, Thomas Schatzl wrote:
...
Compared to the other variants (e.g. with the multiplies, except for the
table lookup) you already save a lot of cycles - although I guess they
would be sufficiently fast anyway, considering the typical uart speeds.
Thomas
Hi Thomas,
My processor flags : -Wpstm32f103rb -Cparmv7m.
The #23 is no typo, I need to reverse 9 bits. I'm using 9 bit
synchronous transmission. My first usart-tests were at 4Mbps. The person
that made the driver recommends max. 6Mbps.
Hi,
I tested some things this weekend. Strange things happen ;-)
The code does not work. Trying to debug with gdb, around the code I got
an error, something like 'recovering from a double fault'.
After searching the STM32 forum of ST I found that some toolchains
assemble the rbit instruction in a wrong way. Someone made a work-around :
.word 0xFxAyFA9y //RBIT Rx,Ry x, y = 0 to F
My Freepascal version is this :
.word 0xFA90
.word 0xF0A0
Then when I disassemble in gdb, I get rbit r0,r0
Disassembling with objdump gives a strange result.
I'm going to try this as soon as I can.
Regards,
Koenraad Lelong.
I have beed using this:-
function bitreverse(input:dword):dword;assembler;nostackframe; {single
instruction rbit r0,r0 bit reverses r0}
asm
.long 0xf0a0fa90
end;
quite successfully.
You can then choose which byte(s) you need using normal pascal functions.
regards,
Geoffrey___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] cross compiler linker issue win32 to Linux
Hi, I have the cross compiler setup(win32 to linux) and I can compile most of my apps just fine except for one that is a daemon and uses cthreads and cmem in the uses. It does not give any errors except for linker error and if I change the verbosity to show all it still does not show anything meaningful. The app won't run on Ubuntu server unless I have cthreads in the uses, otherwise it gives a mutex error about two many threads. Here is the linker errors: Linking project1 Searching file C:\lib\crtend.o... not found Searching file C:\Users\20659\Documents\Lazarus Projects\i386-linux-gnu\crtend.o... not found Searching file C:\Users\20659\Documents\Lazarus Projects\usr\lib\i386-linux-gnu\crtend.o... not found Searching file C:\Users\20659\vbox_share\4.6\crtend.o... found Searching file C:\lib\crtn.o... not found Searching file C:\Users\20659\Documents\Lazarus Projects\i386-linux-gnu\crtn.o... not found Searching file C:\Users\20659\Documents\Lazarus Projects\usr\lib\i386-linux-gnu\crtn.o... found Searching file c:\codetyphon\fpc\bin\i386-linux\i386-linux-ld.exe... not found Searching file C:\codetyphon\fpc\bin\i386-win32\i386-linux-ld.exe... found Using util C:\codetyphon\fpc\bin\i386-win32\i386-linux-ld.exe project1.lpr(16,1) Error: Error while linking project1.lpr(16,1) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted Error: C:\codetyphon\fpc\bin\i386-win32\ppc386.exe returned an error exitcode Anyone have any ideas on how I can get this working? I have all the libpthread shared objects copied over to the windows system. Thanks ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
